I got an opportunity to meet with Alistair Cockburn, one of the Agile inventors. I was fascinated with his simplicity and humbleness.
It is interesting that, last week I watched his ShuHaRi Video, which in turn inspired me to jot down few thoughts trying to predict future of Agile.
I also had an opportunity to discuss few things about the latest buzz DevOps.
Recently, wrote this article for Techwell, and am reproducing the same here. Complete article can be access from this link
It is not uncommon to hear about software project failures., but it's the large-scale project failures that really capture our attention—especially when the problems not only affect a company but the company's customers as well. The recent software glitches and errors that hit the Royal Bank of Scotland and Knight Capital Group damaged both organizations’ reputations and resulted in multimillion dollar losses.
Some of the problems plaguing large-scale projects include communication and coordination errors at multiple levels as well as technology integration and infrastructure issues. Several thought leaders have made attempts in the past to alleviate the impact of these problems on the customers. Craig Larman’s recent book Scaling Lean and Agile Development is a good example. However, no one has been able to identify a silver bullet to address the issues. I doubt there is one.
Recently I came across the idea of a Scaled Agile Framework (SAFe), created by Dean Leffingwell, which is another attempt to help steer large-scale agile projects in the right direction. Synchronization of multiple touch points and early integration testing form the two key ingredients in large-scale projects, and SAFe suggest ways to solve many issues that may arise during these stages.
This screen shot provides an overview of SAFe.
When you see the diagram for the first time, it might look very complex. However, it carries some simple concepts in it. Leffingwell has divided the entire framework into three broad levels: portfolio, program, and team.
Each level has been tagged with clear-cut roles, responsibilities, and artefacts to be delivered. SAFe reuses not only the Scrum framework but also the Feature Driven Development framework in some ways. This reuse ensures that the learning curve is minimal when it comes to understanding the framework.
Even though Scrum popularized the concept of Potentially Shippable Increments (PSI), many teams ignore it. They still continue delivering islands of partially-built products in each iteration. However, SAFe enforces the good behaviour of implementing PSIs through the Agile Release Train (ART).
The ART carries all the features to deliver a PSI, just like a train carrying a cargo. At the end of each PSI, you should be able to test the application end-to-end with limited features. This concept forces the release managers, portfolio managers, architects, and developers to think about integration right from the first Iteration
Read more … here
As far as I know, the bold suggestion of recommending 40 hours working per week came from the XP community through the practice of Sustainable pace.
Even though I keep myself engaged in the Agile community quite upto date, I have hardly seen companies asking employees not to work hard or making it a policy not to work hard.
However, recently came across this article in the Australian news paper where the global CEO of WiseTech has made an unusual request to employees for maintaining work life balance by working not more than 40 hours per week !!
Here are some snippets from the news paper
If employees work more than 40 hours a week regularly, they have to talk to their manager to redress the situation. Workplace expert and University of Adelaide law professor Andrew Stewart said the WiseTech Global approach was the first time he had heard of such a clause applying to Australian workers but he expected the provision to become more common.
He said he expected more claims to be lodged against employers for breach of health and safety laws ‘‘where you have high pressure, high-stress, long working-hours environments’’.
There was increasing evidence that productivity and effectiveness of employees ‘‘falls off dramatically when you have tired workers’’, Professor Stewart said. Recent research argued the effect on employees of working long hours was equivalent to ‘‘being drunk or high on drugs’’, he said.
‘‘Creativity is fired by emotional energy,’’ the company’s charter says. ‘‘ No life balance, no creativity at work.’’
Mr White said he had sat down with employees on about 10 occasions in the past five years and told them they spent too much time i n the office. The workforce consists of salaried, largely full-time employees who do not receive overtime.
He noted staff turnover was ‘‘extremely low’’, an unusual occurrence for an information technology company.
Isn’t this the company everyone dreams to work for ?
It has been proven beyond doubt that Command and Control leadership style a.k.a C2 style leadership does not work. As Dean Anderson describes, the C2 style is based on some of the following assumptions:
The impacts of this style, as described by Dean include:
Command and control as a change leadership style destroys virtually any chance of success in nine out of ten transformational change efforts. For starters, command and control:
Mr Mullen, the chief executive of port and rail operator Asciano in the Australian says,
"(A) seminal shift is under way where employees do not necessarily think that the boss knows best anymore and the power of social networking means that such views are exchanged widely and instantly
He also says ….
"The people we employ today . . . want to be able to bring their own tablet or other device to work rather than using the standard IT department-prescribed personal computer," Mr Mullen says.
"They want to work from home in the morning or the evening outside of work hours, and they want to take flexible holidays and remain in touch while they are away. Social networking is part of their lives."
The danger for managers who want to preserve the old order of nine-to-five workplaces and a hierarchy that assumes the boss is always right is that they lose their best staff. Some may even leave to set up a rival business.
"Failure to embrace the new way of working will literally see older, established businesses go to the wall and Generation X- and Y-led new businesses take their place," Mr Mullen says.
Read the complete article here
Here is my article published on TechWell….
Much has been written about definition of ready (DOR)and definition of done (DOD) lists, but not a lot has been written about the lists’ importance. Additionally, not very much has been written about the issues surrounding these lists.
DOD and DOR lists are similar to the checklists that restaurant chefs use while creating recipes as well as before serving food to customers.
Chefs validate their mental checklists to ensure the availability of ingredients before preparing food. In the absence of this checklist, chefs have to run around looking for each ingredient, which not only wastes time but also stresses out everyone.
I would like to use the chef analogy to show the importance of DOR and DOD lists. Having the right DOR checklist provides you confidence to begin a sprint, and the right DOD list improves a team’s credibility in front of the product owner.
In addition to helping the team check sprint readiness, DOR checklists expose inherent weaknesses of systems. In one case study, a team without a DOR checklist consistently failed to deliver value toward the end of each sprint. However, upon introducing DOR lists, a major issue was discovered followed by a clear solution.
Similarly, having a good DOD list reduces the risk of misunderstanding as well as the communication gaps between the delivery teams and the stakeholders. Always remember to have both DOR and DOD lists together; signing up for a DOD list without a DOR counterpart could result in stressful situations as the teams keep signing up for things without checking their readiness.
Read the complete article published on TechWell
Building a self organizing team is every Agilists dream. Once in a while we hear some stories of successful implementation, and here is the one I came across recently.
Here is a great story I am going to share, but you would be astonished to see that it is not from a software team but a nursing home.
Launched in April 2008, Innovative Care Models provides detailed profiles of 24 successful care delivery models. These profiles were developed as part of a research project conducted by Health Workforce Solutions LLC and funded by the Robert Wood Johnson
One of the models they have applied is the Self Organized Agile team
The goal
Self-Organized Agile Team was developed to address three interrelated nursing problems facing Prairie Lakes Healthcare System (PLHS): poor employee morale due to work intensity and lack of teamwork, high turnover and low productivity.
What exactly they did to build the self organizing team
The hospital placed decision-making authority for work redesign close to the front lines so bedside nurses could make independent decisions and find ways to improve operations. In addition there was a goal to shift to a unit culture in which every nurse touches patients. As a result, jobs were restructured to eliminate nursing roles that did not provide hands-on care. The hospital eliminated the assistant nurse manager, charge nurse, and case manager positions and developed more effective systems to incorporate these clinical leadership functions into the bedside professional nursing role without adding to workload. The unit also eliminated the unit secretary position and blended the responsibilities with the traditional nursing assistant role by cross-training unlicensed staff to fill either position.
Key takeaways from the story
1. They gave importance of hands-on people
2. Replaced the managers
3. Ensured that the decision makers are close to the people on the ground
4. Introduced the cross functional behaviour
Read more here about the fantastic results they have achieved by embracing the self organizing concepts.
Recently Jurgen Appelo’s was in Melbourne,and had an opportunity to attend one of the events. He is the author of two popular books Management 3.0 and How to change the world.
Jurgen is a good speaker, and engages the audience very well. In the event as well he explained various concepts by anchoring European map, and with humour.
What did I learn during the session ?
1. Human beings are driven by the 10 intrinsic desires
2. Jurgen is able to bring Agile methods, complexity theory and systems thinking all together to share new insights.
3. Even though Agile Manifesto talks stress about individuals and interactions, the agilists always talk about the team. Individuals are thoroughly ignored in Agile projects.
4. He also shared about the ADKAR model of change management
5.
Jurgen explained about the desire part through the successful experiment conducted in one of the airports aiming to keep the men’s urinal’s clean. Here is the screen shot of one of the urinals. The Fly is not the real one, it is just a picture.
Psychology behind this technique
The fly etching has been placed in such a way as a means of improving the aim of the urinal's users, thereby significantly reducing spillage and thus keeping the facility cleaner.
The idea is that men using the urinal will almost instinctively aim at the fly with the intent of washing it down the drain and, as a result, spillage caused by poor aim and inattention will be reduced.
I have heard most European countries follow above technique but some replace fly with a Spider 
, thus creating the desire to flush the insect down
6. One has to incentivise good behaviour with small rewards than the large ones.
7. Shared few examples of building collaboration by changing the physical structure of the office space
The PDCA Cycle is a checklist of the four stages which you must go through to get from `problem-faced' to `problem solved'. The four stages are Plan-Do-Check-Act, and they are carried out in the cycle illustrated below.
Source:http://en.wikipedia.org/wiki/PDCA
A lot of people think PDCA was invented by Deming. In reality, it was invented by Walter Shewhart at Bell Labs. But this was popularized by Deming.
Read more here..
The concept of the PDCA Cycle was originally developed by Walter Shewhart, the pioneering statistician who developed statistical process control in the Bell Laboratories in the US during the 1930's. It is often referred to as `the Shewhart Cycle'. It was taken up and promoted very effectively from the 1950s on by the famous Quality Management authority, W. Edwards Deming, and is consequently known by many as `the Deming Wheel'.
Source: http://www.hci.com.au/hcisite3/toolkit/pdcacycl.htm
If some one is embracing Agile methodology with the assumption that they can build a great product, I strongly recommend that they revisit their plan. Great products can’t be built using a good process but by having on board skilled people.
I am going to share some real world examples of a few poorly built products around, and will explain why Scrum, XP or Kanban can’t help, but good UI designers, architects or Product Owners can.
Error message or confirmation ?
Recently I updated some info on a website, and upon submitting the data I received the message shown in the red box in the screen shot below. I am so used to seeing the standard error message in the red box and not a success message. Having a good Product owner(PO) and a User Interface (UI) designer could have helped here in formulating the market standards of displaying the message.
Need help in switching on my washing machine
While I was in Auckland recently on vacation, the serviced apartment I stayed had this washing machine. I never thought that switching on a washing machine is so difficult until I used the one similar to the one shown above. The machine not only had so many knobs, but also the textual info on the left side added a lot to the confusion.I tried all combinations of configuring the knobs and pressed the “Power on” button, but couldn’t start it. I called the reception for help, and the gentlemen who turned up advised me not to worry about the options, and use only the standard setting that works on this machine.Curiously I asked few more questions, and he said,no one knows in the hotel how the knobs work as it confused them all. So, they have learnt only one combination that works.
Again, Lean/Agile or Kanban couldn’t have helped this company to manufacture user friendly washing machine but a good PO, UI designer could have.The PO could have taken the feedback from the real users while approving the design.
Infamous Yahoo attachment problem
The fundamental feature of any email client should be to enable users to attach files to the emails. As many Yahoo email users know, people will go through anxiety attacks when it comes to attaching files to yahoo emails. This is not a new issue, thousands of users across the globe are facing this issue since 2003 – 2004. Does a large company like Yahoo need 8 years and more to fix this problem. I don’t think Lean, Scrum or Kanban will help Yahoo here, but a good Product owner and an architect can.
I think the product owners responsibility shouldn’t stop only till the product is deployed to production, but should continue post production. PO should monitor the product usage, and incorporate the customers feedback.
There are several ways information can be made available to the readers. Cluttered menus are highly unpopular, and mind maps are most popular.
While there is wealth of info on Agile/Scrum on the internet, AgileAtlas has made a good attempt to show the info in a easily navigable way. Here is the screen shot of the website
One could click on an of these topics to get a detailed overview of the same. Best part is the Forum, top guns of Agile (like Ron Jeffries, Mike Cohn, MJ) are the key contributors here. If anyone has any doubt about Agile/Scrum, this is the place to get it answered.
As the software debacles experienced by both the Royal Bank of Scotland (RBS) and Knight Capital Group show, large-scale projects can become large-scale problems. Using a Scaled Agile Framework (SAFe) is one way to help steer these big projects in the right direction.
Recently I came across the idea of a Scaled Agile Framework (SAFe), created by Dean Leffingwell, which is another attempt to help steer large-scale agile projects in the right direction. Synchronization of multiple touch points and early integration testing form the two key ingredients in large-scale projects, and SAFe suggest ways to solve many issues that may arise during these stages.
Read this complete article published on StickyMinds.
Pete Gfader has written this good article about Scrum and Continuous delivery.
Continuous Delivery is the aim of keeping the system “Production Ready” during development and
to release the product to the customer on demand.
What would change if you add “Deployed to Production” to your Definition of “Done”?
There needs to be a high level of trust between the Product Owner and the Development team in
order to let the Development Team deploy every Product Backlog Item. After the deployment to
Production, the Product Owner and the Development Team might decide to immediately release the
latest change.
Read more about this article here
Note: Above image is courtesy of FreeDigitalPhotos.net
Meetings are something which many people dislike for several reasons. One of the common causes is the boredom, and low engagement levels. An Agile coach or a facilitator should monitor the engagement levels of the participants, and drive the meetings in appropriate direction.
Steps to engage audience during meeting
#1 : Circulate the detailed agenda and objective of the meeting before hand. The agenda should indicate the owner, and the time allocated for the topic. The objective should be as clear as possible and less generic.
For example:
Objective: To finalize the user interface for the login screen
Agenda:
* Present the wireframe for the login screen (5 minutes: John)
* Make a list of changes needed for the wireframe (10 minutes: Carla)
* Collate the list of changes into groups (5 minutes: Carla)
* Finalize the list and action items (10 minutes: John)
#2: Many a times it is not possible to exactly stick to the duration allocated for a topic. Some one or the other will come up with a valid topic/question to discuss.This is when,one could make use of the “Thumbs up/down/sideways” decision.
As soon as the timer goes off after the allocated duration, ask the participants if this discussion should be continued on this topic by showing their thumbs.
“Thumbs up” implies agreement. “Thumbs down” implies, disagreement and “Sideways” says “don’t know/not decided”
Based on the number of thumbs up/down, one could sense people’s decision and make the final call.
Fist to Five decision technique
This technique is an extension of the above “thumbs up/down” technique, and could be used to understand the pulse in a more granular fashion.
Sample scenarios
1. The team needs to vote and identify a retrospective item that needs immediate attention at program level
2. Check the confidence level of the team on a specific decision
3. Gauge the impact of an issue on the delivery timelines
4. Identify if the funding is sufficient to run the project
The facilitator could ask the audience to show their support either with fist and with fingers.
Fist could represent --> No support or no vote
One finger --> One vote (full support)
Two fingers –> two votes (partial support)
Similarly, Three, four or Five could be represented either with increase of support or decrease based on the circumstances.
In some contexts, five fingers could be used to say “Stop” or no support.
Try these techniques during your next meeting, and see how quickly one could gather consensus.
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.
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
Joe Woods is one of the top SEO and Internet Marketing Specialists in the Southeast US and has worked with Agile and Scrum since 2007. Joe currently works with Version One and many of the industry’s leading Agile coaches to help IT teams and practitioners evangelize the many different process from Agile, Scrum, XP and Kanban.
1. We started with the black boards  | 2. Before moving to Flipcharts  |
| 3. To avoid marks on the walls, people paste the Post-Its on A3 sized sheets
| 4.Many teams use Glass walls to sketch thoughts
|
| 5. Cling on sheets was one of the effective ways to move notes from one room to another without scratching walls |
The future
Nowadays, many new organizations have started making use of this innovative technology called “IdeaPaint”.
According IdeaPaint’s website:
Titled IdeaPaint, it is available for half the price of an actual whiteboard and works just as well or better, leaving no marks behind when you wash down your work (and, without the rest of the infrastructure, it turns out to be greener, too).
Imagine the ability to write ideas, thoughts, designs and release plan on the white walls without getting worried about the office admin.
If you are a truly Agile enterprise, it is high time to move towards IdeaPaints. I am convinced that, IdeaPaint is going to revolutionize the way people collaboratively work.
Here are few sample pictures of how people use IdeaPaint.
We have heard about ScrumBut and Water Scrum Fall. On similar lines, I thought I would coin another term “Watermelon Agile”.
As we know, watermelon has green outside, and red inside. Similarly, the “Watermelon Agile” projects too show a greenness of Agile outside, however, they would still be “red” inside stuck with Waterfallish mentality.
Some of the Watermelon Agile practices include:
1. They will do Daily Stand ups, but team members are forced to do it. It won’t stop there, blockers are screened before it goes to the blocker wall.
2. They will set up beautiful Kanban walls, but only to satisfy Agile coach or the management, who treat setting up Kanban walls means “Agile”.
3. The Scrum Master still drives the project in command and control mode. Some examples include, asking the team members to report to work at a certain time, micro-managing the team, cultivating blame-game culture within the team.
4. They will still do retrospectives, but team members have fear to expose anything negative about the project.
5. Team members are punished for doing any mistakes. This behaviour automatically pushes the team not to try new things, and in turn the project ends up with no innovation.
Do you know of any other Watermelon Agile practices ?
We are our behaviours, thinking and experiences. Wherever we go, we carry all our emotions and personality with us. A question, do you agree that the way we speak, deal with others are influenced by our past ?
Sarah Taraporewalla of Thoughtworks talked about different personality types, their impact on areas like communication and relationship with our colleagues at work. She presented this topic during Agile Australia 2012 event, a few weeks ago.
She also explained some of the topics like Iceberg principle, TA and positions using her own example as Scrum Master and Agile coach.
Transactional Analysis(TA) describes how people are structured psychologically. It uses what is perhaps its best known model, the ego-state (Parent-Adult-Child) model, to do this.
Eric Berne, founder of Transactional Analysis, believed that each of us have 3 ego states (our Parent, Adult and Child). This is also called PAC model.
The Parent ego state is comprised of the behaviours, thoughts and feelings copied from our parents, or other parental figures. The person with the Parent ego state will spend most of the time giving guidelines.
Adult. 'Adult' describes our ability to think and determine action for ourselves based upon the 'here and now'.
Child. This is the ego state in which individuals behave, feel and think similarly to how they did as a child. Person with Child ego is very emotional. Could cry or get angry easily. People storming out of the meetings, crying when you give a feedback are good examples of a person with Child ego state.
By being in Adult ego state, one could control both the parent and child ego state people.
If you are a Scrum Master or a coach, you could observe the conversations between people, and understand their state. Using the PAC model effectively, one could use appropriate communication mechanism to not only get the work done but also to maintain relationships.
During one of the feedback meetings, the employee I was chatting with started crying. I understood that, she is in the “Child” ego state. As stated earlier, one needs to be in Adult state to manage Child and Parent egos. Being in Adult ego implies, I need to be non threating (Physical posture), and should be in state of enquiry.
Sarah also recommended following books to learn more about Psychology
References:
Understanding PAC model
Transactional Analysis
I am sure you agree that no one is born as an Agile coach. People chose coaching profession based on their strengths. Knowing that, there is a great demand for Agile coaches nowadays, it is always beneficial to understand their journey. Finding an Agile coach is not so difficult, however finding a right one is.
After observing coaches since several years, I found a pattern among their journey. The following pattern could be used as a framework to identify a phase an Agile coach belongs to. If you believe they belong to first two phases, then it is recommended to have a Pragmatic coach to support them.
![image_thumb[1]](http://lh6.ggpht.com/-b-55ndUp05k/T-X46jg6buI/AAAAAAAAArk/2_UENuEypsI/s1600-h/image_thumb%25255B1%25255D%25255B2%25255D.png "image_thumb[1]")
1. Novice phase: As the name implies, new to Agile coaching and diligently follows every step learnt from the past. Very eager to learn new facilitation techniques, and attends all the new training programs, conferences without fail. Very enthusiastic and very vocal about Agile methods in the company.
2. Passionate phase: I understand that, being passionate about something is always good. It carries a lot of good energy, but on the flipside, it could make one blind to the different/better options available.
This phase for an Agile coach is like being a teenager in life, a bit reckless.
During this phase, coach continues to carry a big Agile hammer around all the time. As the saying goes “When you are a hammer, everything looks like a nail”. Whether the customer needs a particular practice or a methodology, the coach will go ahead and push the customer to practice them.
As and when the coach comes across something new, he/she wants to put that into practice immediately on the projects. The coach in this phase strongly believes that Agile/lean practices are silver bullets, which in reality are not.
![image_thumb[2]](http://lh3.ggpht.com/-rMHszkOA_8A/T-X482N695I/AAAAAAAAAr0/DXIPmWptfKg/s1600-h/image_thumb%25255B2%25255D%25255B2%25255D.png "image_thumb[2]")
3. Pragmatic phase: Coach has spent several years working on small/medium and large scale projects. Has gained enough experience working with different clients solving challenging problems. Good thing is, It is easier to identify a pragmatic coach. When you meet one requesting for help, he/she won’t tell you to go, and apply Scrum or Kanban or any popular practices. They would encourage interviewing the key stakeholders,they will also try to understand the issue from an enterprise level before suggesting any solution. These coaches will try to understand the root cause, and provide solutions accordingly.
As I said before, finding the right Agile coach matters. Coaches could influence the bottom line of the company, and having more pragmatic coaches who are not carried away with the hype are always beneficial.
