Agile Atlas - an Informative website

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.

Using SAFe in large Agile projects

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.

Scrum + Continuous Delivery

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

Team decision making techniques – Fist to Five and others

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. 

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

An Outsiders View of Agile Software Development - Part One

Happy to publish this guest post. 

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.


This is my view of the agile software development process from an outsider’s perspective. Now I’m no agile expert, far from it actually. I was always told that we’re an agile shop or that we use waterfall (cringe). Ok, that’s fair enough. All that meant to me was that we do releases every couple weeks or weekly and I have to go to a bunch of team meetings. I also would have to write these things called stories and they couldn’t be too broad and being too narrow meant I missed some functionality. It always seems to be the case that the last place I worked did it wrong, so I always had to learn another way to write a story, how to assign points, and what I had to do to accept or reject a story. Not a big deal once you learn what’s expected.
Now, I’ve been in the internet marketing space for about 10 years now and have had the opportunity to work for many different companies from small start-ups to Fortune 100’s. I’ve had to wear many different hats in this time. Sometimes I was the marketing jack-of-all trades, other times I was the SEO guy, and more recently the consultant/project manager/product manager, slash this or that. Basically, I’ve always been a stakeholder in agile terms. I’ve worked in agile shops, waterfall shops and shops where there is no process. My job success has always been measured by how far I can take the business from points A, B, C and D. It’s vitally important that I get some quick wins starting out to prove my worth and then continue to move the ball or move the needle or get to the next level. Speed and buy-in are always a factor, results are a must, and time is of the essence.
Waterfall versus Agile
Working in a waterfall shop usually meant that I had to spell out all requirements for a typical request, bug, or functionality in great detail. All requirements had to be included and every detail accounted for. I find breaking it down to a very basic level seems to work best here without insulting anyone. Drawing a picture and placing arrows seem to work best to get the point across. Then everything had to go through a vetting process and get signed off multiple times. Waterfall releases were always planned months in advance and pretty much set in stone. This meant that if I started with a company right at the beginning of the new cycle, which always seemed to be the case, then I had months of waiting to get anything done. Even the simplest change took an act of God to make happen, if it were to happen mid-cycle or in the next release. Well, that’s never a good thing as mentioned above and I always knew it was a matter of time before I was gone. Later, I would watch my requests get worked in and the site become successful as a result. This is more of an issue with impatient management and managing expectations on my part than the process itself, but I think it points out the inefficiencies with Waterfall project management.
Fast forward to agile development success. I have to say that I really like agile much better. The reason I like it better is simple: speed. We have more releases which mean I can effect marketing changes and web changes much faster. Sprints can be planned out months in advance as well, but most times they are only planned a release or two ahead. There is also some flexibility in adding additional stories to the queue. So for me, getting a couple stories placed in a sprint or added if the points are available is always a good thing. Marketing things get done faster, numbers come in faster and everyone is happy. More importantly, I get to keep my job. However, agile isn’t without its quirks either.

IdeaPaint– A new dimension to Agile Workspace

Big Visible Charts, and collaborative environment are the distinct characters of Agile workspaces. Many researches have clearly indicated that visibility of information, posture of people and flexibility are the critical elements to enhance creativity. If you are interested to know more about how to improve creativity through a proper design of workspace, read the article here.

In my world, here is how we have used some tools in the past, and at the end, I have made an attempt to predict the future.

Past and present
Depicting/Sharing ideas has evolved over years.

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.

Watermelon Agile

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 ?

How to be an effective Scrum Master by understanding the Ego states

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

How to choose a right Agile coach ?

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.



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.


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.

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.