Writing Archive

159 posts

The role of a Scrum Master in a Distributed Agile Team

The roles and responsibilities of the Scrum Master may vary based on the distribution environment and team structure, but there is always a component that seems to be common for all cases, and this is ensuring that the team is following Agile practices. It becomes imperative in the distributed environment since most of those practices were initially designed for the collocated teams. As a Scrum Master, she/he is responsible for coaching the team and helping them overcome those challenges. Distributed teams can adopt not all Agile practices; some have to be significantly modified, and some will require specific tools, which means that the team will have to invest in some learning time to adopt them. One of the classic examples of those modifications is pair programming. In distributed Agile environments, pair programming is replaced with code reviews. (Personally, I have found code reviews more efficient that pair programming even within the collocated teams). Another practice that is critical in a distributed environment is continuous integration which will ensure that everybody is working on the same code. The implementation of this practice can be challenging from the technical point of view but is well worth the investment. It also requires that all team members understand the importance of daily code check in, even though the particular feature they are working on may not be finished. If the code is throwing exceptions or prohibiting any previous functionality from testing, it should be commented out, but still checked in. The Scrum master is responsible for communicating the importance of Agile practices to all team members. One of the other Scrum master responsibilities usually includes tracking iteration progress. In collocated environments. Iteration tracking is visualized by sticky notes on a wall so that every team member can see the current status of the particular issue, and update the status on items assigned to him during the daily standup meeting. In distributed environment, you need to use something more advanced to visualize the progress. There are fairly large numbers of tools available today in the market which do an excellent job of visualizing iteration tasks, keeping track of backlog items, and generating burn down charts. This is an excerpt from the forthcoming book, The Art of Being Agile.

The Significance of Product Backlog Refinement in Scrum Success

Product backlog refinement, or PBR, is an integral component of successful Scrums. This process of continuously reviewing product backlog items, to ensure that teams know exactly what to work on in the sprints, cannot be done without. It keeps the teams and the product owner on track. To understand why PBR is critical, it is necessary to first understand the details of what PBR is, what we expect from it, and the strategic value it provides.

Transforming Agile Nay-Sayers Into Enthusiasts

Agile is increasingly mentioned as the go-to method for product development, and given the coverage on agile, it appears that there is a consensus that agile is at least viewed in a neutral light, if not favorably. Despite this, there are adamant nay-sayers against agile. For those who are attempting to transition their teams into embracing agile, it can be difficult if a team member is resistant towards agile. This post serves to provide insight into the criticism that some may have towards agile, in order to assist those seeking to convert agile nay-sayers into enthusiasts. For those who hold an unfavorable view of agile, this post will detail the potential of using agile with customer insights to transform products, along with the top agile practices to adopt in order to maximize a product’s reception.Main Criticism Against AgileLack of Structure A common criticism against agile is the lack of structure, especially in comparison to traditional methods such as waterfall. Indeed, agile is more open-ended and it embraces changes. That is not to be mistaken with chaos, though. Critics may misinterpret the lack of structure to lead to team members working on any number of tasks that may be irrelevant, and that progress cannot be achieved efficiently. Agile, in its lack of linearity and openness to quick changes, induces the opposite effect. It enables more progress to be attained during development, as multiple rounds of testing enable product features’ issues to emerge quickly and to be addressed immediately, resulting in a more complete product. Rushes Into Development Some may view the multiple cycles involved in agile to be a “rush” and that it undermines thorough and successful product development. Agile cycles consist of the stages of more traditional methods, but less time is spent on each stage within each sprint. This “rush” into the next stage is precisely what enables agile product development to incorporate so much user feedback into the process – and this incorporation of feedback results in a better product. “Agile Fever” Another main criticism against agile is the apparent “agile fever” that is sweeping across businesses and industries in the attempt to benefit from this method. This criticism is not unwarranted, for as is true with anything, too much of a good thing can be detrimental. With agile, it is important not to rush into implementing it merely because everyone else appears to be doing so; it is vital to thoroughly understand agile before adopting it, and even upon adoption it, the process should be tailored to each business individually. Using Agile With Customer Insights to Transform Products Agile, contrary to the main criticisms that exist, is an efficient method to transform products into ones that are well-received by the targeted customers. Each sprint in agile product development provides the opportunity to glean and incorporate user feedback into the next sprint. Not only is user feedback allowed to be a major factor in the product’s development, but agile also provides ample opportunity for product issues to emerge and to be addressed on the spot, before the final product is released. Under agile, the product is completed multiple times and assessed as such, allowing for it to be enhanced a number of times more than if another method were used. Each sprint in agile product development can be viewed as a trial run, wherein user assessment is gleaned and addressed accordingly. Had the product been developed under a method other than agile, user assessment would not be obtained until the final product was released – by which time it would be more costly to fix the issues and to incorporate what users want and need from the product; the product’s reception and success would suffer accordingly. Top Agile Practices to Adopt To maximize the potential held by agile product development and customer insights, it is important to emphasize the adoption of certain agile practices, namely continuous integration and design review. Continuous integration of feedback results from, and fuels, constant effort to glean feedback on and enhance the developing product. This is vital in creating a more successful final product that matches or surpasses user expectations. Design review, the other top agile practice to adopt in order to maximize integration of customer insights into the final product, enables teams to review design stories with consideration of the latest product feedback; it poses the opportunity to plan further work on the product with the feedback in mind. There will continue to exist agile nay-sayers who will not embrace agile, despite the lack of evidence for some of the main criticisms against agile. For those who are swayed by the potential held by agile to incorporate user feedback into the creation of successful products, there exists ample information for them to begin their agile journey.

Understanding the Team Culture and Requirements

As a coach, it is very complex sometimes how the team who's been coached takes into consideration the minute facts of coaching dynamics and delicacy of human emotions. The turf, as I call it becomes very slippery for the coach to walk on if that’s the case. Agility comes from the fact that everyone should be on the same page about changes that are coming, and discipline that is required to execute that change and gain that acceleration which the organization is looking for.

Understanding the User

This is a very touchy subject. No one wants to be in a position where they are not able to fully support a user. An IT Manager's worst nightmare is the inability to meet the expectations of the users. In a functional organization where the earnings are through the functional means, more or less the It department is on the mercy of the main department. And in order to keep the IT shop running - IT people have no choice but to meet their expectations and fully understand them.

USB Write-Protect / Reset-Erase

Once in a while when I get stuck with something so oblivious that takes a hercules stress, but tends to have a simple solution I turn to Terminal. And I'd my USB stuck with write protect - somehow in rushing from one machine to other you don't allays eject the USB drive properly so it gives you the hellish treatment, I tried formatting using Windows but it still won't write on Mac though will read. In the end I slider towards Mac and used the following utility (found it on MacOSXHints). A much better and simpler solution than downloading any tool or any malware unnecessary.

Waterfall vs. Agile - a thought

Recently I came across this debate on why some companies prefer Waterfall vs. Agile, and I must say that no matter how tempting it is to look the agile way depending on technical needs, but, it all boils down to the business value. Waterfall has been working for years, and is practiced by all organization types - small or big, successful or unsuccessful, and start-up or established. Agile, though has been in the software engineering Eco-space for quite a number of years now, but primarily it has been adapted by companies which are experimenting with projects or programs that have lower risk ratios, or have a smaller enterprise footprint or is intended to produce a faster delivery around time to market for their products or customers. There is truly no one on one to comparison between the two methodologies, and rather both methodologies speak for themselves and at times can be seen as complementing each other, but neither one should be taken as an alternative to replace the other as both of them come with their pros and cons. And they are not in any way shape or form trying to compete with each other. Would be interesting to know other thoughts of how they feel about Agile and Waterfall - either complementing or competing with each other.

Welcome to RapidBlog.com

Finally I'm taking this seriously. Finally I've come back. RapidBlog.com was started in the winter of 2003. The site was hosted at a very affordable host - hence - went down a couple of times; lost contents at times; unfortunately, without any backups. I'm tired of the hosting service, but can't do anything as I paid a year full in advance and now they ('the-hosting-company') won't refund me. So, I say, what the heck. Let it be. Another ordeal for couple of months but this time I'll make sure I've all my proper back ups.

← Back to home