Large Scale Agile development– Key danger and few tips

The biggest danger to large scale Agile development spanning multiple releases  is complacency, and especially around following Agile practices.
For example: After doing the same daily stand-up for hundreds of times, a few teams get bored. They start skipping the daily stand-ups or try to tune in their own way.  
It becomes Scrum Master’s responsibility to ensure that the team gets back on track by identifying the team issues.  I have always found that talking to the team in a non-hostile way helps in identifying the root cause.
It is very important for Scrum Master not to force the practices but sell the idea through discussions and by empowering the team.
Here is a good article summarizing few key ideas for empowering the team.

Coming back to the point of complacency, how to avoid one ? 

Here are few tips 1. Change the structure or time or the location of say Daily stand-up after few months.  Instead of doing at 9 AM in the morning, you could do it at 3 PM. 

2. Identify and rotate the leaders to run some of the Agile practices.  Rotate the anchors. Give a chance to the back bencher to anchors the practices.  

3. Add or rephrase the questions for the daily stand-ups.

4. In one of the large scale Agile development I was leading, initially teams were using the questions “What is working well and Not working well” as part of Retrospective.
After a few months, I changed the questions to “What is working well and What we should do differently ?”
We started using Ideaboardz  for some time and switched over to “Discussion boards”.

5. Do a retro on these practices to get feedback from the team to assess their energy levels

One cannot avoid complacency in large scale and multi release Agile projects, however, by keeping the eyes and ears open, one could mitigate the risks.
Photo courtesy: http://www.freedigitalphotos.net/images/Ideas_and_Decision_M_g409-Solution__p23490.html

Impact of different cultures on Scrum meeting and Retrospective

Scrum meeting and retrospectives are the two key Scrum practices. These two practices provide an opportunity, for every team member to express themselves.  Expression is not only the key message here; the team is allowed to share the impediments, bottlenecks, risks, issues and what is not working well for them.

Photo courtesy:http://www.freedigitalphotos.net/images/Other_Objects_g271-Traditional_Chinese_Knots_p59170.html
Silent Cultures
Some cultures don’t encourage expressing negative feelings in public.  Even when there is terrible issue in the project, the team members will keep saying everything is working fine until the issue becomes so big that it is not solvable. It is not that they want to hide anything, it is just that, they want to silently solve it by themselves.  This cultural problem aggravates if the team is working in onshore/offshore mode.  The onshore members have to rely on the voice or emails, when they cannot see the body language of offshore team.  If you are working on one of those projects, then one would see a no-issue period for few iterations and then a huge panic after that.

Even during retrospectives, one would see a big list of all the good things, and a small list of improvement areas.

Impact: Continued suffering by project members and since issues are detected at a very late stage, additional effort and stress gets added.

Expressive Cultures

Team members from expressive cultures would challenge every issue and bring out impediments upfront.  This provides an opportunity for all the stakeholders to address concerns upfront.  If you are working on one of those projects, one would end up having a long list of impediment issues and retrospective items to cover.

 

I see more pros than cons here. Some times decision making becomes difficult as the team members would end up spending a lot of time debating issues.

Photo courtesy: http://www.freedigitalphotos.net/images/Mature_Men_g217-Expressive_Old_Man_p46710.html

Hierarchical Cultures
Hierarchical cultures have a  strong command and control style of leadership. Typically, a lead represents the entire team and makes all the key decisions.  The team members just follow the directions from the lead with no questions asked.  The team members will be like “Blinkers” on horses eyes.  They can only see or hear few things from a window given by the lead.

Impact
>>  The team members will only share impediments/blockers that are allowed to be shared by the lead.
>> The team members find it difficult to make decisions on their own
>> The impediment list from Scrum meeting and the feedback items from the retrospective will have a pattern of certain issues only. Because, these are the only patterns that are allowed by the lead to be shared to the outside world.

Photo courtesy: http://www.freedigitalphotos.net/images/Other_Business_Conce_g200-Organisation_Chart_p36927.html

Let me know if you have other stories about the cultural impact on Agile practices. Am happy to publish it.

Top 200 Blogger

I found out recently that  My Agile Blog has been rated as one of the Top 200 Blogs on Agile. 

Check this link out: http://agilescout.com/top-agile-blogs-200/

Right now I am on 155 .   This number could change depending on so many parameters.   I am excited though.

What’s the first Decision? Implementing Kanban vs Scrum

Happy to publish this guest post by Michael DePaoli

. Author’s bio at the end of this article 

What’s the first Decision? Implementing Kanban vs Scrum by Michael DePaoli

If your development team or manufacturing team is considering moving to using Kanban vs. Agile Scrum, one of the biggest decisions is choosing the right agile development methods for the job. Let’s discuss the realities of implementing Kanban and some of the fundamentals that hold back both Kanban and Scrum implementations.

On paper, Kanban is certainly easier to kick-start from a change management perspective because you can leave current roles and processes largely intact; you just need to get commitment from the business to adhere to three basic principles:

1. Provide a high degree of visibility/transparency of the state of all work queued and in progress
2. Establish and respect WIP(work in progress) limits in the value flow
3. Commit to execution in a ‘pull-based’ manner from the prioritized work queue

Yeah, just get commitment and practice of these three things… Much easier said than done in my experience because they are frequently outside the circle of influence of those driving the change to implementing Kanban!

Usually it isn’t that the agile software teams are unable to execute under Scrum; the fundamental issue is that the business isn’t willing to accept a “pull-based” execution model (required for Kanban and Scrum).

Businesses continue to make irresponsible commitments to customers and investors. This only perpetuates crystal-ball thinking, fixed-date, fixed-scope and fixed-cost projects. It’s the classic sales-driven model we see all too often where the sales arm doesn’t respect the capability of its product development group to produce predictable value for the customer in a timely manner, and with an agreed-upon level of quality. After all, quality is a business decision.

This irresponsible action ends up causing organizations to be unpredictable in their delivery, have lower quality, and to burn out their teams.  These outcomes in turn destroy brands, ruin company reputations on Wall Street,  increase the percentage of each investor dollar serving up technical debt (in lieu of adding new value to products), and causes instability in the organization’s systems due to turnover.

 

 

Bottom line, if an organization can’t make the commitment to respect their product development system’s proven delivery capability at the current level, neither Kanban nor Scrum will provide predictability.  But even in the face of this dysfunction, agile methodologies like Kanban and Scrum can still provide faster learning to teams, which allows them to test their assumptions faster and provide more value to their customers by delivering what they actually need.

In conclusion, I leave you with this advice:  ignore the myths and hype about Kanban. Before you can make any decisions on the Kanban vs Scrum debate, you must first evaluate:

• Your organization’s product development and sales culture,
• The nature of the demand for service from product development,
• The competency of your organization to plan and execute change, and
• The degree to which you’re willing to face the truth

Only then can you choose the best agile software tool for the job.

Image Courtesy: http://www.freedigitalphotos.net/images/Ideas_and_Decision_M_g409-Choices_p23497.html

Over his 26 years in IT, Michael DePaoli’s experienced has included serving in different traditional roles in highly respected companies. The roles have included analyst, software engineer, quality engineer, development manager, project manager, Director of Engineering, VP of R&D, CTO and Consultant in companies, such as American Express, Sprint, Deloitte Consulting, Sapient, Knowledgepoint, Adobe Systems, AOL, NetApp and VersionOne. Michael works as an agile / lean coach and product consultant with the VersionOne services group.

Impact of culture on Agile practices –Why now ?

There are several forums discussing this topic of impact of different cultures on Agile practices. Have you wondered why is this topic suddenly gaining so much of importance now ?.  Specifically, a lot of questions are being asked in the context of implementing Agile practices.

Image courtesy : http://www.freedigitalphotos.net/images/Africa_g240-Africa_p28543.html

I definitely see that culture drives how people interact with each other.  Since most of the Agile projects follow the Value
“Individuals and Interactions over process and tools”,  these interactions start highlighting the impact of culture on the way we work.

 

In traditional waterfall model,  interactions were minimal, and there was no demand on the people to do so.  For example, there was no need for them to attend the daily stand ups to share their bottlenecks, there were no retrospectives  nor show cases.

Following practices implemented in Agile projects improves the interactions

1.  Daily Stand ups or Scrum meetings

2.  Product Owner Demos or Reviews

3.  Showcases

4.  Retrospectives

5.  Sitting together with no cubicle boundaries

6   Co-located teams

7.  Use of Wikis  as opposed to Sharepoint

In the next few days I am planning to write some articles on the actual impact of culture on some of the practices.