Blog

Notes, articles, and updates.

⭐ Featured Jan 11, 2017

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.

featured

More Articles

Jan 09, 2017 · 1 min read

Selling Agile to Senior Management

The best way to promote Agile to senior management is to explain its numerous benefits and cost and waste reduction methods. Once key players in the organization are made aware of Agile’s benefits, it essentially sells itself. And, the best way to sell a methodology is to demonstrate its value by delivering quantifiable and visible business benefits, but to even get there, you first need to find a project that you can implement using Agile, and this is a challenge in itself. The process of selling usually starts with a presentation to the key decision makers, which should at least cover the following areas:

featured
Jan 02, 2017 · 1 min read

Role of Software Architect in Agile Projects

One of the biggest misconceptions about Agile is that architecture is not required in the Agile development. ‘We‘re Agile; we don’t need architecture’–is something that everybody involved in Agile has heard at least once. Let’s start by establishing a common understanding of what the software architecture is, to which everyone can agree. The definition of architecture is quite broad, and the roles and responsibilities of software architects vary dramatically from company to company. Here is how Martin Fowler identifies architecture in Patterns of Enterprise Application Architecture: "Architecture" is a term that lots of people try to define, with little agreement. There are two common elements: one is the highest-level breakdown of a system into its parts; the other–decisions that are hard to change.” I find that we all can agree on those two common elements. Do we need the highest-level system break down? Absolutely. Do we need huge documents and long design stages? No. Agile is not against the architecture–it’s against useless, bulky documentation that nobody reads anyway. From the perspective of change, the role of architecture in Agile development becomes quite clear - A good architecture is responsive and will support agility; a poor architecture will resist it and reduce it. And, since one of the benefits of adopting Agile is a better response to changes in the requirements, it’s obvious that flexible and extendable architecture is a key to this. The biggest issue that I’ve noticed is the very thin line between architectural design and software design. I’ve seen companies where the different implementations of the following practice were used: Architects created design documentation and developers were responsible for writing the code. This introduced a myriad of problems, starting with developers feeling that they were not fully trusted. This also gave developers an excuse not to really think about the design. ‘We’re just coders, not responsible for the design and we do only what we are told to do.’ is a common attitude that I have witnessed. In Agile, the developer is responsible for the code he writes (and unit tests) as well as the design since nobody else will provide him with it. Ideally, the high-level software architecture is completed before coding starts. And I really have to be careful here - completed doesn’t mean written in stone; it can change, but with an understanding “this is the best of what we know right now.” This doesn’t necessarily include a database design or class diagram, and the level of details really depends on the approach you will be taking moving forward. I found that for certain systems the Domain Drive Design (DDD) is extremely useful and has made my life far easier. Therefore, I like to have a domain model and a basic set of domain classes and their relations defined, but not to the level of methods and attributes. Personally, I prefer projects to have a design stage; this is when the high-level business domain model and user stories are created. At this stage the main architectural decisions are made – the technology that will be used, the database server, the application type (for example, Mobile, rich client, or service), the architecture style (client server, layered architecture, SOA) is selected, and the architectural frame that will be applied is selected as well. The document created during this phase is not solely architectural effort, it is a collaborative effort of business analysts, developers, and network administrators. The output of this design stage is not only a high-level architectural document. (This is not an attempt to make fixed predictions of the future or create a detailed software design upfront as this approach places all the significant decisions at the point of least knowledge in a project's lifecycle). This is simply a way of getting and sharing the common understanding of the system we are all about to develop. This is an excerpt from the forthcoming book, The Art of Being Agile. [Image Courtesy: Flickr/Helix/Philip Gunkel]

agilefeatured
Sep 23, 2014 · 1 min read

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.

featured
Sep 17, 2014 · 1 min read

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.

featured
Sep 08, 2014 · 1 min read

Reasons Why Agile Coaches Must Get Their Hands Dirty

Agile coaches must be involved in the client's Agile process. Those who have the impression that coaching can be done from the sidelines are mistaken, for coaches must get their hands dirty if they want to bring about successful Agile adoption. To better explain why Agile coaches cannot be observers, I will provide details about the possible mayhem within the Agile landscape, some twisted thoughts about coaching, and the high-level transition plans that Agile coaches should set in motion for their clients.

featured
← Back to home