Agile and Post-Its

For many,  Agile projects and Post-Its are synonyms, and do you agree this is a misconception ?.
This misconception has gone to such an extreme that, some believe that if you are not using post-it notes then you are not Agile. This looks funny for many Agilists, but this belief is true with many newbies.  One might be interested to understand the origin of this misconception.  Let us start with Information radiators.

Information Radiators

Information radiators are not a new concept. Lean thinkers and Toyota teams have been using this from many years. This concept was popularized in the Agile world by  Alistair Cockburn through his book Agile Software Development.   Since Post-its are handy and easy to use they became popular as information radiators across the globe.

In my opinion, Information radiators are just like any other tools. As the Agile manifesto says,
“Individuals and interactions over process and tools”.   So, one needs to be cautious of using the tools appropriately.

Now we know that Post-Its are just like any other tools. One should be cognizant of their usage in Agile projects. Even though, I have taken the example of using Post-Its here, this is applicable to all tools. Let us see some uses of Post-its.

Teams use Post-It notes to display

• the status of User Stories (Analysis, Design, Build, testing, etc)
• the quality stats
• Impediments/Risks/Issues
• etc.

My experience says that teams reject tools or the tools become unusable if

• wrong tools are used even in the right context
• If the right tools used in a wrong way

Especially, tools play a key role in large scale and long term Agile projects.

Large Scale and long term Agile projects

In the long term projects, over use of Post-its leads to what I am terming as “Post-It Noise”. The wall not only gets cluttered, but people will stop updating the walls.  There are a few who have reported stress due to the cluttering of wall due to unplanned growth of Post-its on the wall. 


I am not against using the Post-it notes  however one needs to be cognizant of  maintainability of them on the walls.  A wall with a beautiful display of Post-it not only adds value but gives a pleasant look.


  http://ericlefevre.net/wordpress/2007/11/17/reflecting-on-our-open-space-technology-event/

Summary

• Use Post-It notes based on need. If the teams are comfortable using flipcharts, White boards, let them use it. Don’t force people to use Post-It notes for every task.
• Arrange Post-its or cling on sheets in a pleasant way
• If you find the teams not updating the wall, do a retro and see if the wall is really adding value

Useful resources

• Visual Display of Quantitative information provides an overview of communicating the data effectively in a graphical way
• Visual Management of Agile Teams
• Trusting a yellow sticky ? Good luck with that
  
  
  
  

Velocity : Myths and Misconceptions

Velocity is one of the simplest but powerful tool to predict the future completion date of the project.

What is Velocity ?

Velocity is the capability of a particular team to deliver certain set of requirements within a specified duration.

It is very important to note that, this is true for a particular team with a fixed duration.  If the team and duration changes then the velocity changes automatically.

Based on my past experience interacting with several teams, I found that following misconceptions misguide the teams.   As an Agile coach or Scrum Master, it is very important to help the team to understand the true meaning of Velocity and drive away the myths and misconceptions.

Myths and Misconceptions 

Wrong	Right
Velocity is productivity	Remember,  Velocity is not productivity.  Productivity is how busy your team is. When some one is measuring productivity, they don’t measure the value generated out of it. Productivity is also measured against a standard.  However, Velocity is for a particular team, particular context and in a specified duration.  Velocity could be tied to business value.
Velocity Standardization	Many leaders think of standardizing velocity across multiple projects and sometimes throughout the organization.  This is totally wrong. As said before, each team is different, trying to enforce velocity of one team on another results in increased stress, loss of morale, productivity and finally loss of value to the customer.
Converting Velocity measured in Story Points to an absolute number in Person days	I have seen many Scrum Masters trying to convert the Velocity measured in Story Points to Person days. For example, 80 Story Points = 60 Person days.  Again, this is wrong. The above conversion basically freezes the delivery capability of the team upfront.  If the team is new to a technology or a business domain, the capability to deliver would be less. By freezing the story points upfront, the new team would struggle a lot and will get stressed out.
Comparing Velocity among teams	Since Velocity is specific to a team and within a context, it does not make sense to compare the velocities between teams.  A team comprising of Oracle Experts working on Oracle technology obviously will fare well as compared to a team of  fresh out of college put on a similar Oracle project.  Velocity of both the teams would be different. Never compare velocity between teams

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.

Kanban vs Scrum Myths and Hype– Guest Post

by Michael DePaoli

It is my pleasure to have Michael DePaoli contribute articles to my Agile blog.  Michael comes with rich experience in IT  and the detailed bio is at the end of this article. Happy reading.

Recently, I heard folks at a few of my clients and at a couple conferences talking about why they are considering moving to using Kanban vs. Scrum. I have no preference to either method other than choosing the right agile development tool for the job.

My concern derived from what I have heard identifies the beginnings of some myths and also demonstrates some of the hype around Kanban. 

First, a clarification;
>> Kanban with a capital (K) is the term David Anderson coined with respect to an agile development approach to driving change based on lean principles.

>> Kanban with a little (k) represents the idea of the “sign” or “billboard” that provides the signal/visibility in a production line for additional demand for service of a particular station.

It is one of the tools that enables just-in-time (JIT) action as described in the Toyota Production System.

Kanban, as Anderson explains in his book, relies on change occurring in more of an optimizing manner (see kaizen culture).

David Anderson's Kanban book

This is the significant difference between Kanban and Scrum. In a Kanban approach, an organization can begin with their current practices with a few exceptions.

Kanban requires:

A high degree of visibility into the state of all work queued and in progress

Absolute respect for WIP limits

A commitment to execution in a ‘pull-based’ manner from the prioritized work queue

Kanban also demands a focus on quality. In fact, this is Anderson’s first step in his six-step recipe for Kanban. Quality comes first primarily because of the obvious cause-and-effect relationship to waste — and because it’s generally more in the direct control of technical management. Working down his recipe, there tends to be less control and influence over the changes by technical management.

Now for the Myths and Hype

Myth: 
>> Scrum has work pushed onto the team while in Kanban work is pulled into the system. This is incorrect. Scrum does not have work “pushed through the system.” It is a pull-based agile development system with work pulled in larger batches (the Sprint Backlog).

>> A Scrum implementation (as well as Kanban) becomes a ‘push-based’ system when the business doesn’t respect the current proven capability of its teams to produce value and just continues to push demands for service into the system.

Doesn't just apply to

>> Kanban

Hype: Kanban at its core is summarized by the premise: ’Stop Starting, Start Finishing’. The entire team’s focus is on ‘getting to done’ for the tasks in progress. This statement is certainly true of Kanban, but the implication that Scrum does not have this focus is not true. Scrum done right has the same focus, delivering software sooner and doing so in priority order to maximize the value delivered to the customer. I’ve coached to Scrum teams for years that, wherever possible, everyone on the team should work on the highest priority item and get it done first before starting on the next item in the Sprint Backlog. This implies limiting WIP, as well as focusing on delivering the Backlog in rank order.

If the focus of a Scrum team is to just get everything in a Sprint Backlog into an in-progress state, regardless of priority, then you have a dysfunctional team that’s most likely not working cross-functionally and certainly not focused on delivering the highest-value items first.

Hype: The statement, “The Kanban method is intuitive and is quickly and easily adopted by teams,” to me is a statement that’s used irresponsibly. It is too often a battle cry of those trying to sell Kanban as a product. It is the cop-out reason used by many organizations who are failing at Scrum and looking at Kanban.

Author Bio :

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.

Scrum Smells - Rarely Quoted

We  know the popular Scrum Smells  like

1. Scrum meeting with a  large team
2. Scrum Master assigning tasks to the team members
3. Velocity being used to measure the productivity of team, etc

However, following 4 are rarely called out in open forums even though they are like elephant in the room.   

They are
1. Hierarchy: Product Owners considering superior to the team (specifically Business Analysts). Consider the existence of a hierarchy here.
2. Business Analysts mostly being used for  typing User Stories
3. Agile coaches considering them as superior human beings as compared to the rest of the team. Basically, dictating terms and reserving the right to answer questions from team members. 
4. Software Services vendor continuing to call “Customer as King” but not directing the King in the right direction by pointing mistakes.

Even though 3 and 4 are not specific to Scrum, they still are relevant.

Productivity is not equal to increased Profit

Have you ever been part of a tool selection team ?   Have you proposed procuring any new tool to your supervisors ?


Image: John Kasawa / FreeDigitalPhotos.net

I have done this many times. I have been part of  such tool selection committees.  Most of  the times we as developers are impressed with the new tools for many reasons.  The reason for falling in love with a tool could be because of :
1. Ease of use,
2. Stability,
3. More features,
4. Better communication, etc

All the above reasons are valuable, and in addition I have seen most commonly quoted reason being "Improved Productivity".

Let us discuss more on this subject. If the tools getting procured are going to have an impact on multiple groups, one should look at impact of productivity in one group on the other.
Let us take a fictitious  example of Product owners procuring a tool that can generate User Stories with a click of a button.  Product Owners are now productive, and they have increased generating User stories by >20%.   What if we don't have similar tools at developers end to churn out these stories ?
These generated user stories would go and sit in the backlog  as inventories, which are wastes.


One should be cognizant of the fact that Improved productivity may not  increase in the bottom line. In fact, it might cause bottlenecks and increase in inventory.


One of the key things to ensure improved productivity is by limiting the work in progress (WIP).  If a tool that is getting procured is going to affect WIP, it has negative consequences on the system.

Whether the tool is a high resolution communication device or a simple document repository one, the stakeholders shouldn't get carried away only looking at productivity.   If the stakeholders intent is long term investments, they should look at the impact on their bottom line.  Tool selection might increase productivity in one corner of the organization but might impact the bottom-line at the other corner.

Summary: Tools are important for the organization. During tool selection process, improved productivity shouldn't be the driver for new investments.

Agile Teams to Avoid

Recently  received a request from  SmartBear  representative to share  one of  Infotoons created by their team with the Agile World blog readers. 

Here you go..

Scrum Video Tutorials by Jeff Sutherland

Recently came across this amazing library of Scrum Videos. These videos are recorded as interviews with Jeff Sutherland, co-inventor of Scrum.    Jeff explains the concepts in these short videos in a crystal clear way. 

Enjoy the videos by visiting this link

Top 5 Articles from 2011 and New Year Wishes

Being in Australia, just started our new Year 2012.  Looking back at 2011, glanced at Google Analytics to see the popular articles. Out of nearly 2 dozen or so articles I have posted  since the last 12 months, almost all articles have more than 3 digits page views.   Thought would shortlist the most popular ones and share it with the readers.

 

I have edited the Top 5 articles into a clean brochure kind of PDF document.  Feel free to download them from here.

Wish you all a very happy new year and warm wishes for the year 2012

Photo courtesy: dreamtime.com

Definition of Ready template for teams - A free one for download

Have you come across teams struggling in iterations bombarded with surprises ? I have seen many times. 
Teams and POs  concentrate mostly on “Definition of Done”  by keeping the end in mind, which is good. However, it is also important to evaluate the readiness before entering the iterations.
As we all know, Garbage in – Garbage Out,  if the team starts Sprints/iterations with weak information, the output produced too would be of poor quality.

 

In one of the case studies, Team didn’t have the acceptance criteria for all the user stories. But they were convinced by the PO that, it would be detailed out during the iteration. The team signed up and  incidentally, things didn’t go as per the plan. The team ended up building a few stories with incomplete features.

Imagine having a robust checklist which is used as the gateway into a Sprint. Noting is allowed into the Sprint fort without getting clearance from this gateway.    This gateway is nothing but Definition of Ready(DoR) Checklist.

 

The Definition of Ready checklist will have the list of items that need to be in place before stepping into the iteration. 

Some examples include,

* Clearly defined User stories are one of the key items to be ready before the iteration planning meeting
*  A healthy backlog with enough stories for atleast 2 iterations
*  Healthy Dev and Test environments
*  Availability of team, etc

A few points to remember

* The DoR checklist is a living document and should be kept upto date with the learning from each iteration. 
* Scrum  Master could own this document. 
* The list should have the inputs from not only the Scrum Team but from Product Owner(s) ,Scrum Master, Business Analyst and other stake holders. 

I have created a DoR template with typical items needed to kick start using it. This is not an exhaustive list, but gives you a feel of DoR items.  Feel free to download the PDF version of the template from here.   This is free to use as a starting point for building DOR checklist.

Secret recipe behind Amazon’s software development methodology

Have you ever wondered What is the secret behind some of the successful product companies ?  

Have you ever wondered what methodology do these companies follow in software development ?

Right now, my favourite companies include  Amazon, Apple, Facebook and Google. I don’t miss a chance to read information about their org structure, software development process, recruitment process, etc.

In this post, I would be uncovering Amazon’s strategy while building a product.  Before Amazon starts building any product, they write the following documents  Press Release, FAQ, Customer Experience and User Manual.  
Press Release is a short 2 or 3 paragraphs note about the product as though it would be published in a newspaper.
FAQ  as the name itself implies covers the frequently asked questions about this product. Questions with What, How and Why trigger thoughts for the stakeholders to see missing pieces of information.

Customer Experience this document captures the stories about customer user experience. This could happen through Mock-up screens or use cases.
User Manual  covers the way the product to be used. 

Following picture depicts this process.

They don’t spend months together in writing these documents. These documents are crisp and cover the information on a need basis. They involve all the relevant team members from technology, and business while preparing these documents.

The benefit of this process is, it provides a greater clarity around the product that needs to be built and avoids the confusion.
I feel that these documents could also be used as:
        a. Training manual for new joiners 
        b. Requirement spec  

Do you have stories or secret recipe to share from successful companies ?

How to be an effective Product Owner ?

Product Owner (PO) plays a pivotal role in Scrum projects. As the saying goes “Garbage in – Garbage out”, if the PO provides poor quality requirements, the developers churn out equivalent code, and in turn an inferior product.  We keep seeing a lot of failed products in the market. If we track back and identify the root cause of these products, it would have some connection to the requirement gathering phase.

In Scrum, the product Owners own the backlog. It is extremely important to do due diligence while choosing a PO. Larger organizations running multiple projects, and many releases find it difficult to identify good product owners for all projects. They end up picking and sending any one with some knowledge of the domain and tagging them as POs. This is dangerous and inefficient way to fill such a key role.

Based on my past coaching experiences on several  Scrum projects, I have found several factors influencing the PO role. I have put together these factors in the form of a picture. Scrum Projects will be very effective if the following points are kept in mind while identifying a suitable person for the PO role.

 

 

Following brief explanation is not in any specific order

1. Lack of Agile/PO training: It is important for designated Product Owner to have undergone Agile, Scrum and Specifically PO trainings.

2.  Organizational Complexity:  Large organizations with several groups, sponsors and IT departments creates their own complexity .  I am sure experienced coaches working with large multi national corporations would vouch for this.

3. Lack of domain knowledge: There is nothing worse for a PO to be leading this role with no proper domain knowledge.

4. Leadership Style and Personalities: Even though no Scrum book talks about this point, I feel it is very important for a PO to be

     * Pragmatic
    * Ability to convey the goal and vision
    * Not getting irritated with questions
    * Empathetic
    * Collaborative rather than Command & Control

5. Not enough Authority:  POs with inadequate authority in making decisions, not only leads to waste due to sign off processes, but also creates frustrations among POs.

Are you aware of other factors impacting effectiveness of PO ?

Who should be blamed for a failed Scrum Project ?

An interesting discussion about  Who should be blamed for a failed Scrum Project ? in Scrum Practitioners forum  made me to write this short article.    

As I started putting the comment together to respond, I was getting more questions than answers.

Here, are some of my thoughts:

• Personally, I feel that as long as there is a blame game culture around, the weakest one gets the blame. My experience has been that being more vocal one could push away blame easily.
• As far as I know, there is no democratic debate to nail down the culprit, its all about witch hunting.  Following paragraphs provide additional reasoning.
• Wearing a purists hat, Trust is the foundation of all the work. Whether it is Software or non-Software work, Whether one follows Waterfall, Six Sigma or Agile. Failure is a hall mark of Mistrust.
• Failure will not happen just like that one day. It is the culmination of issues built up over a period. The issue keeps accumulating every hour/every day. Scrum Meetings, Retrospectives were recommended to catch the issues at an early stage before it leads to FAILURE. With the context of Scrum in mind,
Here is the list of few more questions one should ask:

• Did the team raise any issue at all during the Scrum Meeting ? If not, why not ? 
• If, they had raised the issues, did the Scrum Master track it ?
• Did Product Owner attend the Scrum Meeting regularly ? Did he/she catch the issues ?
• Are the team afraid of bringing out the issues upfront ? Who is influencing this behaviour?
• Did retrospective happen regularly, and issues were brought out during retro ?
• Did stakeholders/Sponsors attend the retrospective ? Did they show any interests in the “What is not working well” column ?
• If the team is not following any of the Scrum recommended practices, project itself is initiated with the wrong footing. Should someone be blamed for this ?


Answers to the above questions evoke a different set of answers and emotions.

Before ending this article, let me share a good quote 
As Karyn puts it:
Blame gives people an easy out. If it’s not your fault then it’s not in your control. If it’s not in your control then there is nothing you can do about it. If there is nothing you can do about it, then you don’t have any obligation or any need to try to change. If you can blame someone else, somehow, it lets you off of the hook

Duration of Iteration 0

Iteration 0 is typically the duration between the initial “Discovery” and “Evolve Phase” of a software project.  As such, there is no formula or a number to determine the iteration 0 duration, which suits all the projects.

I use the following check list to decide the duration

1. Duration of the project :  If the duration of the project is small, then one should be cognizant of spending a lot of time on Iteration 0. 
For a 6 months or 1 year project 1 week of  Iteration 0 should be good enough.

2. Pending items : These are the items which could negatively impact starting of Evolve phase.  Based on my coaching experiences on many projects, I have managed to create a checklist of things typically needed to start the actual development.  

Some of them include:
     a. Development and testing environment readiness (licenses, Hardware, etc)
     b. Is Backlog healthy and ready to support one or two future iterations
     c. Do we have the team ready with the right skills
     d. Does the team need any training before they start the coding
     e. Does the team have all necessary tools to start the project
    
If  the team does not have basic things, then there is no meaning in starting the development and waiting in between.

3. Did it exceed > duration  of 1 iteration ?
The iteration duration varies from project to project, and stays between 2 – 4 weeks (max) in most of the good Agile projects.
I always tend to suggest that the Iteration 0 should not exceed duration of one iteration.  In my world, if Iteration 0 needs more time to finish then there are more challenges ahead for this project.

Notes from Lean workshop - Vol 2

http://www.techno-science.net/?onglet=articles&article=3&page=3
The Empire State building construction is  a classic example of  application of Lean principles.  It was built within budget and in time.

Here are the few success factors that lead to this achievement.

 

1. Team work: Owner, Architect and the Builder. 

In a software development scenario the above team could be compared to the Sponsor, Architect and developers.   Notice that there is no product owner.

Mary, recommends that product lead should have both technology and business acumen. This is opposed to the concept of Product Owners, who are purely coming from business background.

2. Builder was highly experienced in building such large scale systems.

3. Identifying and focussing on the key constraint: Material flow. 

4. The design was based on less coupled systems

 

5. Every one was made aware of the key constraint that was the cash flow.  Every day delay caused nearly 10,000$ (~120,000 $ in today’s term).

6. Constraints were kept in mind while laying out the plan, and not based on the design.

Notes from David Snowden’s lecture

November month provided me rare and very good opportunity to attend workshops anchored by renowned speakers across the globe. 

It started with David Snowden’s workshop on Complexity theory  followed by  Mary and Tom’s leaders window.  


David is known for his contributions towards knowledge management and Complexity theory related subjects.  He has won several awards and a very good speaker.

The 2 hour I spent listening to Snowden is memorable.  I had a few Aha moments during the workshop, and based on Snowden’s pointers, I am continuing research on the areas related to complexity theory.  He is one of the inspiring speakers I have come across. The venue was crowded with eagerly looking lean thinkers and Agilists.

A few points from my notes :

1. Building Inefficiency provides opportunity for innovation

2. Systems thinking provides an idealistic and futuristic view, where as complexity theory looks at current state of affairs

3. One learns things better by failing rather than doing it right or reading “How to” books

4. Complex systems are dispositional but not causal

5. It is important to know the principles, and “why” behind the principles to scale it.

Notes from Lean workshop - Vol 1

Mary and Tom’s Leaders workshop  had been insightful, and a few thoughts are extremely radical in nature. The notes I took during the conference span a few pages, and would be sharing it here in the next couple of posts.

Got Opportunity to have lunch with Mary, and got an opportunity to take a few pix with her during the conference.

1. Involve diverse team during any decision making process. Healthy conflict is one of the key ingredients in building a successful product

2. Having a meeting like Scrum meeting/standup every day is always useful. However, Mary recommends the Pulse Meeting model that is followed at Scania 

3. Functional requirements should be considered as unarticulated high level designs.  Reading between the lines, there is a hidden design in every functional requirement.  This is also echoed by Tom Gilb.

4. Having a Product Owner between the sponsorer and developers adds waste.  Share the vision with the developers and let developers/technical people take it from there in building the product

5. Find a way to write less code

6. 25 – 30 % Productivity can be increased by eliminating Task switching

7. I was under the impression that PDCA cycle was invented by Deming but learnt that it was Walter A Shewhart from Bell Labs

8. One should be cognizant of  applying the competency or technical leadership styles while forming the team.

9. Also, discussed  Little’s law and Queuing theory in addition to practicing few case studies of its applicability in software projects

10. Trying to utilize 100% of bandwidth reduces the pace rather than improving it. 

Yow Conference Australia

Looking forward to attend Yow Developer Conference next week.  The conference has pretty good and popular speakers. Some of the popular speakers  include Martin Fowler, Mary and Tom Poppendieck,Linda Rising, Joshua Kerievsky, Eric Evans. 

Leader's Workshop, 2 days workshop by Mary and Tom is going to be an important workshop for me to attend.

This workshop is going to cover the following areas:

• How to discover what customers really want.
• How to look at your process from a customer's point of view and identify waste.
• What's wrong with software testing and what you have to do to fix it.
• How to engage people and stimulate focused innovation.
• Scaling patterns that have proven successful - and their context.
• How to frame risk and rethink scheduling to permit confident promise-dating and reliable delivery.
• Tools for solving problems that everyone in the organization can use.
• Leadership roles that work - from the perspective of followers.
• How traditional governance systems can lead to sub-optimization and what to do about it.

Who is best positioned to write a User Story ?

Someone with a strong domain knowledge is suitable for writing User Stories and It is typically a person close to the business.  Having said that, I strongly believe that  everyone  in a Scrum team should know how to write User Stories.

Reflecting back on Ron Jefferies’s Circle of Life, User stories have 3 key aspects:  Cards, Conversation and Confirmation.

Conversation is the key aspect to be noted here.

This is how a typical User Story writing conversation takes place:

1. Some one from Business (Product Owner(PO) or Business Analyst(BA)) would write the Story on a card.
2. They keep this card on a table and invite the delivery team including developers, architect, testers, etc into the conversation.
3. The delivery team will ask questions to understand the story and in turn BA or PO would make a note of these changes, but any one standing there could pick up the card and make necessary changes to the User Story card.
4. Technical people (Architect, DB admin, etc) get involved if the discussion is tilted around technical user stories.
5. Product Owner is the final approver of all the User stories
 

Depending on the size of the project, dedicated people (typically BAs) should be allocated to write User Stories.
In smaller projects, Product Owners can write User Stories.

Problem with specialization

I  saw the above poster on a closed restaurant near my apartment.

First thing that came to my mind seeing this poster was “Issue with Specialization”.   

Let me share this a bit in detail:

Looking at the poster, it is clear that Chef is unavailable for 4 weeks as he is flying abroad to visit family. Due to chef’s unavailability the entire restaurant is closed for 4 weeks (or until his return).

Since Chef is the only specialist available with no “Cross Functional” team in the restaurant, any issue related to Chef impacts the entire restaurant.

Using this analogy on software development, the projects are at high risk when we have specially skilled team members with no backups .

On a lighter note, while reading the poster, you might also feel that the restaurant is being run by a non-English speaking owner.

Agile Contracts

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Writing contracts is a key topic for the sales team getting involved in Agile projects.  In the  projects applying traditional methodology, companies had zeroed down on two popular models that are: 

1. Fixed Price and
2. T & M (Time and Material)

While working on Fixed price model, software vendors would analyse  the requirements upfront and commit to a price with the customer.  Many a times, the customer fixes a price and the committed bidder gets the project.  

The uncertainties involved in the software development makes this model a flawed one.   As per the popular and well researched  Cone of Uncertainty,  the initial estimate done at the beginning of the software project could be +/- 400%

 

off-mark than the actual calculated at the end.   In order to mitigate these uncertain risks, companies participating in these contracts have to add a lot of unscientific buffer to accommodate them.

Projects applying Agile methodologies is supposed to have a flux associated with them. The scope could change any time and this needs to be accommodated in the contract and this is not easy. This is one of the reasons for Fixed price contracts not being popular in Agile projects. Even though there are several case studies of application on Agile projects but at the end of the day, the constraints imposed by Fixed Price model might actually destroy the agility.

Photo Courtesy: http://www.construx.com/Page.aspx?cid=1648

Time & Material(T & M) as the name implies is supposed to work well for Agile software development as it has no restriction on price or scope. The customer can keep paying as long as the value is getting delivered. However, my observation has been that this model works  well in an established trustworthy environment. 

Several experiments have been made in creating contracts specifically suited to Agile environments.  Some of them include:

1. Phased Delivery
2. Capacity Based
3. Value Based

Phased Delivery contracts divides the entire project life cycle into multiple different phases. A goal is set for each phase and funds are released based on the delivery. The goal could be the number of user stories to be delivered in each phase providing additional quality related info.

Capacity based contracts would provide X number of people for the project  and no scope related delivery constraints are signed.

I am also envisioning Value Based Delivery contract, and I am not sure if some one has experimented with this.  I feel that, either a $ value or some unit could be assigned to Epics or to user stories theme.  As and when this gets delivered, proportionate amount of fund could be released. Again, quality related matrices could be an additional parameter in the contract. 

An Agile practitioner  has put together a list of 10 styles on Agile contracts . check this link out for more details.

Summary
I strongly believe that  Trust and Contract are inversely proportional to each other. That is, as long as we have less trust, we need more contracts.

Copyright protected 2011

Managing the Agile rooms

Large Agile projects need larger rooms. Even then, they get filled with  Post-It notes in a short span of time.After some time, It would be difficult to find an inch on the wall to add additional information leading to a chaotic  environment.  Clean, well organized space provides clarity in thinking too.

Some of the key things to watch out include
1. Watch out for stale information on the wall. Find a way to archive the old one.  In one project, we used a large box in a corner to archive old post-its.

2. Post the items in a logical order
3. Identify a few people in the team to manage the wall. Creative people could make a difference.
4. Create a lay out such that anyone entering the room can reach the right information easily.  Without a layout, it looks overwhelmed and confusing.

 

 

 

 

Do you have other suggestions to manage the wall ?

Revisiting 3rd question from Scrum Meeting

 

We all know the most memorable, and the key question of the Daily Scrum Meeting, which is
“What are the roadblocks in achieving my goal” ? 

Typical roadblock answers we hear include:

1. I don’t have the development environment ready yet
2. We don’t have necessary skilled people to augment the team
3. We have not received the licenses yet for the software
4. We have a key person missing in the team

 

 

 

 

 

and many variants of above issues.

The Scrum Master records the blockers, and no doubt takes action on them.  However, over a period of time, my observation has been that,  just sharing the blocker is less efficient. I feel that one should also share the impact of the blocker .

For example the above blockers could be reworded as

1. I don’t have the development environment ready yet, due to which I cannot start iteration 1
2. We don’t have necessary skilled people to augment the team so, we cannot start the project .

Yes, it is implicitly expected that the impact is automatically expected here, but it never happens.

As soon as the “impact” is shouted out, it creates its own listening . It pushes the people to think from the goal perspective rather than just removing the blocker.

Summary:  The answer to the 3rd question could be reworded as
My roadblocks are … . and the impacts on this project are….

Let me know if you think it makes a difference ?

Scrum Practices waste of time ?

Every day in some part of the world, I can definitely feel that one of the software projects is getting transitioned to Agile methodology.   Many of the developers working on these new Agile/Scrum projects feel overwhelmed with the new and different practices.

Let us see the typical practices followed in Scrum :
1. Daily Stand ups

2. Sprint Planning Meeting
3. Sprint Reviews

4. Sprint Retrospectives

By the time these “New to Agile” developers, complete their 3rd or 4th iteration, they will start cribbing and saying,

“Oh, these practices are a waste of time, we can deliver more user stories  if we are allowed to sit and code”.

Agree, they can deliver more user stories, but can they guarantee a superior quality code, a valuable product meeting customer’s requirement ?

Let us see why this is not a smart idea to skip any of these practices.

Scrum is all about  Inspect and Adapt.  
Every now and then, one needs to stop, take a deep breathe, inspect the current set of practices, analyse them well.  If one finds areas of improvement, make a list and strive to adapt the good practices.

Skipping these practices might seem to gain some time, but indirectly it causes more harm than good.

Well known thought leader Ron Jefferies says

In my opinion, if four hours a week[spending on different practices] make any difference, you're cutting things too close. You're likely to make at least one four hour mistake by not planning and tracking.


Summary: Unless you really know what you are doing, don’t skip any of the Scrum (or any other Agile methods) practices. Especially if one is new to Agile, then just follow the book until one gains maturity , experience and good understanding.

Can defect fixing be counted as part of Velocity ?

Many a times developers come back with the question,

Can I consider  defect fixing  as part of the velocity ?

Broadly speaking I have seen following types of answers
1. No, do not track it as part of velocity
2. One  should negate these points from the velocity
3. Track it in a different bucket

Let me explain the above types in detail.
1 & 2. Do not track it as part of velocity and may be one should negate it :  Many thought leaders believe that, tracking defect fixing leads to double counting of velocity. People who advocate this believe in delivering quality code with ZERO defects, each time and every time. Velocity is measured as part of delivering a quality code with no defects.  So, the defect found in the future is nothing but your past sin in creating the defect. They believe that, rather than asking for credits,  deduct the velocity.

Many developers feel that deducting velocity is more like punishment, and punishment will not improve the code quality.  There has to be a better way.

3. Track it in a different bucket :   Instead of worrying too much about deducting or not tracking,  go ahead and track it.   Try to have “Defect Velocity” as a separate bucket. During estimation, one could look at the Defect velocity and plan the “DBT(Design, Build, Test) velocity”.
There will be some defect lurking in the code all the time. Even the complex and popular operating systems  like Windows OS and iOS have defects in the shipped product.
As long as the “Defect Velocity” bucket is predictable, its in a good shape.


Summary: Type 3 feels better than Types 1 and 2

Tell me which type do you follow in your project ?

Tools to build Big Visible charts

The commonly available tools for Agile teams to build "Big Visible charts" include,

   Post-it Notes
   Butcher Sheet
   Flip Charts
   White Boards  

However, while traveling to different countries, and currently in Melbourne I have come across additional tools like:

  Blue Tac 
     Blue tac is like a reusable Gum.  Typically Post-It notes stickiness is not so great.  So, one can use Blue Tac to increase the stickiness.  One can also use Blue Tac to stick the cards, butcher sheet or strings.  Blue Tac can stick to glass panes, wooden boards, etc.  

  Cling on Sheet
      Put it simply, these are reusable butcher sheets
       

Blue Tac                   Cling on Sheets 
 
Ref: orbostofficesmart.com.au

I also found that it is an art to use these tools properly and arranging them in a way to please the eyes. 
 
One can just stick the Post it Notes on the walls  like below:
 

Or, order them clearly by separating them either with the strings or with Cello tapes like shown below:

Ref: brunomiranda.com

What other tools do you use ?