Key ingredient for success: Systems Thinking

Our behaviour is always a reaction to the system around us. Let us take an example of an Agile team working  on a project, and as we know its behaviour would be determined by the stakeholders, leaders, enterprise culture around them. Anyone wishing to  change the team’s mindset should look at changing the system first rather than their practices.



^{Photo from Flickr: http://www.flickr.com/photos/jmurawski/499278540/}

As per Systems Thinking a problem needs to be solved by looking at the system as a “whole” rather than the reaction to parts of the system. All the elements in a system are inter - related and inter - dependent.  Removing parts of the system creates a new system destroying the old one.  

In any software project, the system includes the developers, testers, stakeholders, and all the tools being used there. Agile transformation is all about changing the mindset of the people towards embracing a better way of developing software. An Agile coach on the project will be successful, only if he/she has the power to influence the system, not just the practices. However, it is not the case in most instances. Most of the Agile coaches concentrate only on Agile practices and updating the Kanban walls. This has lead to large scale failures in Agile projects, and at the end stakeholders  declaring “Agile won’t work”. 

Based on my experience I see the following issues leading to failure of Agile coaches

1. Lack of Systems thinking knowledge
2. No “teeth” or sufficient power to influence the systems. This typically happens when Agile coaches are hired to solve specific project issues 
3. Lack of experience working in large enterprises or systems. Coaches with hands on experience working on multitude of projects are in a better position as compared to newly “upgraded” coaches.
4. Ignoring the importance of systems, and trying to impress the clients with Scrum ceremonies.

There are several mitigation strategies to address the above issue

1. Ensure that Agile coaches understand the concept of Systems Thinking, and are knowledgeable enough to use the right set of tools
2. Agile coaches need to be empowered and supported to change the system. As long as their hands are tied, they end up improving the ceremonies, and not the system
3. Agile coaches should closely work with iteration managers/Scrum Masters in brining the change. While Scrum Masters concentrate on the practices, the coaches should concentrate on Systems Thinking.

Agile Coaches likes and Dislikes

Are you afraid of uttering certain words in front of Agile coaches for the fear of getting branded as “Non Agilist” ?

I have seen many places where the teams dread using “Non Agilie” vocabulary.  I thought I would make a list of words that  Agilists like and Dislike :-) 


Let me start with the words they don’t like to hear

• Process
• Standard
• Sign Off
• Hand off
• Change Request
• Manager
• Reporting Structure
• Hierarchy
• Distributed Development
• Command and Control
• Tracking
• Approval
• Fixed Bid Contract
• Rules
• Documentation
• Productivity
• GANTT Chart

If you like to get some attention from Agile coaches around you, start using the following words:

What the Agile coaches like

• White Board/Post-Its
• Servant leader
• Time & Material
• Kanban Wall
• Open Source
• Colocation
• Self Organization
• Autonomy
• Elimination of Wastes

If you know additional words, feel free to share it here.

Articles I read recently

I  read a lot of articles, blogs and white papers.  Some of them really make you think, and some to retrospect.   Here are some that I read recently.   Click on these screen shots to read the entire article

An Outsiders View of Agile Software Development - Part Two

 

Continuing the guest post article : An outsiders view of Agile Software Development – Part One, here is the second and final part of the series.

This is my view of the agile software development process from an outsider’s perspective. Here’s what I don’t like about Agile or what seem to be the most common issues:

1. You’re doing it wrong…

What I don’t like about agile, now this is just my experience, is that it seems very rigid in many ways. I think too many developers and project managers are way too strict on the process piece. It has to be by the book or it’s wrong and must be done over. Every place seems to do it differently and no one seems to do it the “right” way according to the developers or project managers. I’m not talking about a couple of instances, I’m referring to most places where I’ve worked that use agile. Am I wrong in thinking that agile was created to be adaptive to whatever environment where it’s used? I don’t think there is one right way of doing it, just some basic guidelines and see what works for you.

2. Wording the story

Too many team leaders are quick to throw something out because the story wasn’t written a certain way or the story is too long. Maybe this is a control issue, but it seems to irk some people when things aren’t worded a certain way. Usually when this happens, I have to rewrite the story or break it out. Ok, no problem, but let’s try to be “agile” about this and cut a stakeholder some slack. Developers don’t like the dreaded ‘R’ word (rework) and as a stakeholder, I don’t like having to rewrite things if you can understand what I’m requesting. The process isn’t going to break if the story isn’t worded a certain way.

3. Meetings, meetings and more meetings

The other issue for me is there are way too many meetings that have to take place. Take for example one company I worked at had 3 development teams, 10 developers per team, with one dev team per division. I was a stakeholder in all 3 teams which meant that I had to go to 3 stand-ups every morning, 3 estimation sessions, 3 sprint planning meetings every other week, 3 release meetings, and 3 post release meetings. If I didn’t go to these, then I wasn’t viewed as a team player or supporting the process. That’s a lot of meetings and time considering my job isn’t a project manager for each, but a stakeholder in all. Now I know this is just one company and does not represent all agile shops, but there are a lot of meetings either way. Keep in mind as a stakeholder; I also have reports to create, other meetings to attend and I still have to deal with other departments. Not to mention doing my own job. Let’s try to cut down on the meetings or get the stakeholders out fast especially if they only have 1 or 2 stories in the sprint.

My Conclusions about Agile

What I like about agile is the speed and flexibility to get things done. The process used in the development does matter and can mean the difference between success and failure or in my case job or no job. There seem to be common issues at every place I go. No one seems to do agile right, their words not mine. Writing an agile story varies in different shops, who does the QA is different and who accepts the stories is always completely different. It seems to be a process within a process and learning the nuances is important to get along with the team. Meetings are important, but seem to be overbearing in a lot of ways. Let’s streamline that process if we can and reduce the number of meetings. Overall, I still like agile and there is more sense of a team environment. I can say I owe a lot of my successes to the agile process and I can live with the quirks. From an outsider looking in, it’s not a perfect process, but I think it’s a must have to be innovative and successful in the fast paced internet marketing space.

Photo credit goes to: http://marcestes.com/wp-content/uploads/2011/02/Doing-right-thing.jpg