Value and Culture over practices and processes

On Day 1 of Agile Australia,  Sandra Dalli  and Sarah McAllister of Bank West shared their experiences adopting Agile at  BankWest.  BankWest is into the beginning of their 3rd year of its Agile adoption and bringing Agile into the organisation has involved so much more than delivering Agile projects.

During this session, the speakers shared not only their success but their failures during the journey of Agile adoption.  One needs to appreciate the fact that, they didn’t paint a rosy picture saying their journey was easy.  One of the triggers for the bank to adopt Agile was the massive failure on a water fall project. The team on the waterfall project spent several months writing requirement specifications and design documents burning the project budget, and at the end realizing there is no money to build the software.

Before sharing their journey, let me share my experiences of Agile adoption in large organizations.

Based on my past experience, an organization goes through the following phases during Agile adoption. As shown in the picture below, there are 3 key phases. 

1. Learning and Experimentation
2. Initiation
3. Matured 

The details of these phases are explained below mapping BankWest experience.

1. During Learning and Experimentation phase, the enterprise typically takes following actions to initiate the Agile adoption:

             a. Identifying a point of contact to run the Agile show
             b. Form a team or group to drive Agile related activities
             c. Hire or get Agile coaches on contract
             d. Create training programs and start enrolling employees into this
             e. Start one or more pilot projects and experiment applying Agile methods

BankWest went through steps similar to one mentioned above ending this phase successfully. Another key reason for their success so far is the support from the top management. I could clearly see that they had applied Top-Down Agile adoption  strategy.

When the speakers were given the baton to start Agile adoption 3 years ago, they spent nearly three months going through various websites, and documents researching everything about Agile. They also wrote a lengthy manual for everyone to read, which they made fun of as they realized later that this is not the right way. 

Regarding Agile coaching, I think they took help from Lonely Planet.

2. The initiation phase is all about embracing Agile as much as possible.  The BankWest speakers shared the way they brought testers and developers collocated as part of their journey. They were serious in bringing Agility to their company, and they followed every recommendation given in Agile books and ones shared by Agile coaches.  

As we know, implementing a new practice or skill across organization takes anywhere between few months to years. It is always recommended that new practices should be encouraged to be adopted incrementally than in a big bang way.  

Incremental learning
BankWest took 5 practices(Daily stand up, retrospective, showcases, etc)  as priority and encouraged all teams to practice only one at a time for a month, before moving onto the next one. At the end of 5 months, they saw most of the projects well versed with some of them.  The entire organization was amazed to see this transformation happening in front of their eyes.  

Read more about Agile adoption phases and the J-Curve effect here

Currently BankWest seems to be at the end of this phase.

3. Matured Phase: During this phase, pretty much all the infrastructure needed to do Agile projects should be available handy.  Matured Enterprises start looking at Agile adoption beyond software delivery, and starts including HR, Finances, etc.  Some of these activities could be started during the second phase itself depending on the size and maturity of the organization.

During the conference, I listened the journey of BankWest, NAB and other companies. My own experience of Agile transformation in past companies combined with this clearly shows that, there is no secret recipe to succeed in the journey of Agile adoption. Every company has it’s own culture and DNA. Don’t try to copy set of practices of another company with the hope that you would succeed. 

Every organization has to invent and carve a path for themselves. Teams will fail many a times. However, as long as they are learning from their mistakes, they should be encouraged and supported in their journey.   One thing is clear, identifying the right group of people to steer the journey, and hiring good Agile coaches during the beginning makes a lot of difference. 

How to build a high performing Agile team ?

 

Building a high performing team is a dream of every Agilist. Agile Australia event had a track on this topic too.  Mike Bromley of NBN covered this topic on Day 1 of the event.  As part of building a high performing team, the first step is to hire talented people.  According to Mike,

                   Culture is a driving force behind performance, and people = culture.        

He also mentions that 9 key traits of a good performer. I have put together the traits in the screen shot below.

As one could see, it is difficult to find all the talents in one single person. One needs to carefully chose people so that, they complement each others skill. Some of the talents mentioned above(courage, innovation,etc) cannot be identified using the typical interviewing (Q&A) technique. Special techniques are needed.

Here are some of the special techniques

• Microsoft interview process
• SOARA technique
• Uncovering soft skills
• Interview beyond technical skills
• Different interviewing techniques

Agile Australia 2012– Successful event

 

Two days of Agile Australia 2012  ended last week. The organizers had put a lot of effort in making this event a success.  The key notes on both the days were inspiring, and the topics during the event not only touched upon Agile methods, but also included  leadership and case studies from various companies. 

Food was good by the way, the weather wasn’t bad. Since the venue was within Melbourne city, the commute was easy.

I would be summarizing some of the learning in the next few blog posts.

Agile Australia 2012

 

Looking forward to attend the Agile Australia sessions starting tomorrow.  Looks like the venue is running with full capacity with conference tickets sold out.  

We have so many good tracks running in parallel, and it is making me difficult to decide the sessions.

Feel free to follow the conference using the Twitter hash-tag  #Agileaus.

Litmus test for an Agile company : practicing Sustainable pace

 

      Nowadays with the advent of  blackberries and smartphones, the work hours are no more restricted to 9 to 5.  These devices can download emails any time any where, and in turn has enabled professionals to work as per their wish. 


According to a recent survey by Neverfail, a software company specializing in data protection,

83 % of professional workers say they check email after work. 
66 % take a smartphone or laptop with them on vacation and
more than 50 % report that they send emails or texts during a meal with family or friends.

It is obvious that checking work related emails at home carries the mental pressure associated at work to private life.  This in turn has triggered more questions than answers. They are..

is this a healthy way of living/working ?    
Should an individual take responsibility to balance work and life ?  
Is there a role that an organization can play here, if so, do they get any benefit out of it ?

Even though the individual has a key role in finding their own work/life balance, I feel that employers have an equal role to play as well in this era of globalization.    Let me share a few researches to support this idea.

Firstly, according to a study by Dov Eden of Tel Aviv’s University’s, 

Employees who feel compelled to be at the beck and call of work at all times are unlikely to recover from the ill-effects of chronic job stress. This is a causal chain that eventually gets internalized as psychological and behavioural responses that can bring on serious chronic disease.

The employees checking emails during their vacation, will come back to work to get burned out more rather than a relaxed vacation. Burned out employees in turn are less efficient and less productive draining companies resources.

Secondly, as per the famous Predictable time off experiment conducted by BCG, the consultants who had time off felt happier and better at their jobs than those who did not. They were also more efficient. One of the teams that participated in this experiment decreased its average workweek from 65 to 58 hours while accomplishing essentially the same amount. Isn’t this more efficient for the company ?     Today, BCG teams that join the predictable time off program meet regularly to work out schedules so that every member can take an official break from e-mail one night each week, not including weekends.

Keeping in mind some of the above mentioned issues of  workers getting burned out, Volkswagen has programmed its e-mail servers to stop sending messages to many of its German employees after their shifts end.  Isn’t this a good move by such a large company to help their employees and in turn themselves ?

eXtreme Programming(XP) introduced Sustainable pace a long ago. Now it is turn for the truly Agile companies to introduce  programs like Predictable time off, shut down email servers during the weekends to help employee burn out and improve the productivity.  I truly believe that supporting the idea of Scrum or XP or Kanban is not going to make a company Agile, but introducing above ideas is the true litmus test for an Agile company.

New Skills for the Agile Team

Agile development teams live and die by their code. Many have found in practice that “good” agile code is extensible, low-defect code with the simplest robust design that will work for the features currently implemented. Among the agile methodologies, Extreme Programming (XP) goes into the most depth concerning how programmers can keep themselves and their code agile. Below are some new skills that agile teams need to embrace.

Simple Design

Agile teams are under pressure to deliver working, tested code at the end of each iteration and their code must be capable of turning on a dime at any moment. So agile teams place enormous value on the extensibility of their code: the extent to which they can easily maintain and extend it. The other key component of extensibility is design simplicity. Extensibility seems to be inversely proportional to design complexity.

Refactoring

Refactoring is the process of clarifying and simplifying the design of existing code, without changing its behavior. Agile teams are maintaining and extending their code a lot from iteration to iteration, and without continuous refactoring, this is hard to do. This is because un-refactored code tends to rot. Rot takes several forms: unhealthy dependencies between classes or packages, bad allocation of class responsibilities, way too many responsibilities per method or class, duplicate code and many other varieties of confusion and clutter.

Breaking Down Work

Agile methods promote taking large projects and breaking them down into a coordinated series of smaller projects developed by smaller, cross-functional teams. The various teams’ work (i.e. code) is integrated at least every iteration in order to reduce risk and ensure functional and technical compatibility.

Continuous Planning

An incremental approach to planning allows for initial planning at a high level, and iterative planning at lower levels as more knowledge is gained. As teams begin to learn what they can deliver on a daily, weekly and monthly basis, they become more accurate at both their short- and long-term planning abilities than they ever were with traditional planning approaches.

Providing Input

Collaborative decision-making techniques are important because agile requirements definition involves more than just the Business Analyst and the Product Owner. Agile encourages input from all team members to create a more robust solution that meets the needs of the business and helps create a strong sense of confidence that the solution can be delivered to market.

These are just a few of the new skills agile teams need to embrace. Learn more about other Agile Programming Practices.

7 tips to hire and manage Agile coaches

Large organizations transitioning towards Agile take the first step of hiring Agile coaches.  Many business leaders would be under pressure to hire one as quickly as possible to speed up the process of Agile transformation. Many a times, due to this pressure, they end up making a mistake, hiring a wrong one. 

Based on my past experience working with large organizations and different coaches, I have put together the following 7 points to help business in making good decisions.

1. Try working with 2 or 3 coaches before finalizing one.
2. If you are planning a short term consulting role from a coach, then hire some one who has already built a good credibility as a coach. You may not have enough time to experiment.
3. Ensure to have only one Agile coach on a project.  Having 2 or more could end up wasting time/resources, as two Agile coaches rarely agree, especially if they are from different companies.
4. Ensure, coaches have skin in the game.
5. Ensure that Agile coaches know how to use available tools/technologies rather than just hung up on using Post-It notes.  Let me share my own experience working with one of the best Agile coaches Craig Larman.   While working with Craig, I noticed that, he not only used  Post-it efficiently,   Craig encouraged us to use different tools like  Cling-on sheets, White boards, Flip-charts, Projectors,etc.  Many Agile coaches nowadays don’t think beyond post-it notes.
6. I have observed that newbie-coaches who are on contracting roles tend to buckle up under organizational pressure. They may not push for changes to happen. An Agile coach who fearlessly pushes for transformation is better.
7. If you have hired an Agile coach, then observe the coach during their assignment for few days to understand their areas of strength.
   
   

Top 3 Myths of Agile Development

 

Agile development is an umbrella term for a number of iterative and incremental software development methodologies such as Scrum, Extreme Programming (XP), Lean and Kanban. With agile, all aspects of software development – planning, designing, coding, integrating and testing – are combined in short, frequent iterations.

Agile software development is not a silver bullet, but it has forced many to rethink traditional approaches to software development and apply new ideas and techniques in an effort to build better software faster. As with any significant industry shift, a tremendous amount of fear, uncertainty and doubt generally accompany the transition.

Myth 1: Agile development is undisciplined, cowboy coding.

Fact: Continuous delivery of running, tested software every few weeks could be characterized as the ultimate software industry discipline.

Myth 2: Agile development isn’t predictable.

Fact: Agile teams are constantly planning, prioritizing and delivering against the plan and have a much better sense of where the project actually is and what can be accomplished.

Myth 3: Agile development is just another fad.

Fact: Many industry leaders have embraced and promoted agile. Agile adoption has moved from small co-located teams to large divisions and software organizations of enterprise IT.

What’s Hot: Agile Development

· Teams constantly delivering benefit to the organization every quarter, month, week or even day

· Small, cross-functional teams that communicate and collaborate on an on-going basis

· Planning projects upfront at a high level with detailed planning happening throughout the project to efficiently adapt to change

· Using historical information to plan work incrementally and predict progress

· Quality software is always ready to be delivered

What’s Not: Traditional Software Development

· Teams delivering new features once or twice a year and often missing release dates

· Large teams that meet infrequently and are too big to have meaningful collaboration

· Extensive, up-front planning crammed into the beginning of a project that doesn’t account for inevitable change

· Using speculation to plan all work upfront and “predict” progress

· Passable software is delivered late

Learn about more myths of agile development.

Does a Scrum Master need technical or functional background ?

 

Do you expect your Scrum Master to understand  Java coding standards ?  Should the Scrum Master have a deep understanding of  differences between the four products the customer is building ?

There are people supporting the idea of Scrum Masters with strong knowledge in technology/programming skills. I feel that, knowing a specific subject whether it is technical or functional is never going to hurt. However, in the context of being a Scrum Master, I strongly believe that it is not a mandatory skill.

As long as the Scrum Master appreciates the value of technical practices, and importance of having a good technical debt in the project, one can always take help from a technical/functional coach or expert to implement the practices.  

Fundamentally, I see that following skills are essential to succeed as a Scrum Master

1. Ability to identify the technical or functional experts within the team (or the lack of)
2. Finding ways to get the help for the team
3. Skill to remove the impediments/blockers
4. Appreciate the value of good technical practices
5. Asking the right set of questions to get the answers
6. Empowering the teams to succeed and build self organizing teams

Let us take a look at an example. Consider a scenario where in a developer shares a blocker saying
                                               The message to TIBCO server is failing.

The Scrum Master(SM) need not know how to fix TIBCO server issue. As long as SM asks the right questions, the impediments could be removed and one could succeed in any project.

A SM could ask following questions in the context of above TIBCO server issue (not in any specific order)
1. Is this a new one or the one occurred in the past ?
2. Who are the TIBCO skilled experts in the team to be invited to investigate this issue ?
3. Do you really think it is TIBCO server issue or something else ?
4. What is the criticality of the issue and who should be informed ?
5. What is the fall back plan ?
6. What is the impact of this issue on delivery timelines ?
and few more questions…

In the end, the SM could do a retro (if it is major issue), and apply 5 Whys to identify the root cause.

Agile testing Vs Traditional QA

 

Exploratory testing   : Business requirements on an agile project may not be as concrete as requirements on a traditional project; agile methods accept that change is a healthy and real part of software development. This means that test case generation may not be as cut-and-dried as it was in the past. Exploratory testing is an essential skill to uncover additional considerations for the product owner to evaluate.

Automation

Agile emphasizes automating as much as possible, but many teams struggle with when, how much and what tools to use. While continuous integration (CI) is an accepted developer practice, agile testing takes the lead on incorporating automated acceptance tests and creating regression test plans as part of CI.

Communication

Traditional QA engineers tend to rely on documents. Agile testing QA engineers don’t get a big requirements document as a basis for test cases and don’t get three months to write test cases before they see a working piece of code. They jump into the communication stream, which may be verbal, written or virtual, and assimilate the information they need.

Challenges with Traditional QA:

· Significant delays between when software is written and development receives feedback

· Defects found late in the process can have major implications when changed

· Changing business requirements affect test cases that have already been developed

· Siloed communications create risk that different groups may have different expectations of the final product

· Quality suffers and many QA activities get left out when testing is the last activity before a fixed release date

Benefits of Agile Testing:

· On-going feedback to developers allows testers to ask the right questions at the right time.

· Early identification of dependencies, technical or testing challenges and roadblocks.

· Embraces change as a healthy and real part of software development.

· Team collaboration helps everyone work together toward a common goal.

· Quality comes first because final acceptance criteria are established prior to the work beginning.

Learn more about Test First programming, and how to transition from traditional testing to agile testing.

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.