Lors de son passage à Montéal le 14 juillet, KenSchwaber a accordé une entrevue à Vincent Tencé. Découvrez comment réussir avec Scrum, visionnez la vidéo!

http://visualstudiomagazine.com/Articles/2010/07/27/Installing-Scrum-Process-Template.aspx

Urban Turtle 3.2 fully supports the new Visual Studio Scrum 1.0 Process Template. Using the index card metaphor with drag-and-drop functionality, it is the perfect replacement for Excel-based planning workbooks.

Tweet This Post

So you have initiated an Agile transition and have faced some resistance to change! Or maybe, you assessed your current level of Agile Maturity and are hoping to achieve the next level. Better yet, you and your team are planning to launch an Agile transition that is not driven by the wrong reasons.

That’s great!

If you haven’t already done so, you may want to read: Getting Started – Reference Material for Managers Who Wish to Understand Agile and Scrum and What consultants don’t tell you before you begin an agile transition.

Let’s cut the chase and get to the point. Are you ready? Here it is. The secret to a successful Agile Transition -> Make people look good!

Yes. That’s it. Surprised?

I’m not talking about psychological manipulation. I’m talking about finding what drives the people you are working with and the managers around them and then capitalize on their drivers in order to get them to get on board with the transition – and better yet become evangelist for your transition. Here are some examples:

• Suzy is hoping to get promoted to Vice-president within her organization. She heads a business line from which you need support and a dedicated Product Owner. Why don’t you explain to Suzy how innovative her group would appear to others if she agreed to embark on the Agile initiative?
• Peter is struggling to increase the performance of his group. So far, he hasn’t shown much interest in the transition but you found out that he has been under high pressure from his manager to increase the performance of his team. Why wouldn’t you show Peter how using an Agile approach could help get his manager off his back?
• Monica is a project manager who has lost several key people in previous months. She is usually by-the-book (i.e. PMBoK) but during a recent lunch, she admitted that she would be willing to try something different if only it would help her retain the contributors she needs to make her project successful. Why don’t you take this opportunity to get the project manager on board with Agile by offering to help her?

Don’t get me wrong. I am not asking you to lie, to cheat or to fake the objectives and expected outcome. I’m telling you to get others on board and working WITH you by telling them the whole story and helping them understand that there is something in it for THEM too.

Agile relies heavily on communications and interactions. Why don’t you start with all the people directly and indirectly impacted by the transition? Sure, it will require more time in the short term to influence people into supporting you but in the long run, you will be glad you did it.

Go ahead. Try to figure out what drives people around you or what issues they are facing. Find a solution that can help them and you’ll end-up with a win-win scenario and a successful transition.

You might be interested in these related posts:

1. Agile Transition – What about the teams outside the transition?
2. Book review: Outliers: The Story of Success
3. What consultants don’t tell you before you begin an agile transition – Part 3: Impact on the functional and people managers

In the coming weeks, I will publish a series of blog posts to give you more detail on each of our partners. I started this series with a first partner, the firm Northwest Cadence.

Northwest Cadence is an American consulting firm located in Kirkland, Washington.  They consult, coach, and train organizations to help them perfect their software development processes. They orchestrate the cadence between technology and teamwork to ensure organizations get triumphant results. Through a focus on team capability, Application Lifecycle Management, and optimal tooling such as Urban Turtle, Northwest Cadence is here to make you a winner and keep you smiling.

Steven Borg, founder of Northwest Cadence explains why they appreciate Urban Turtle:

“Urban Turtle dramatically reduces the tool friction involved in adopting agile with Team Foundation Server.  By clearly removing a significant agile adoption blocker, Urban Turtle helps teams ‘get’ agile more quickly and adopt more successfully.  I’m currently recommending Urban Turtle to all our clients adopting agile.  It eases the transition and teams love it.”

You can find an engaging compilation of Technical Tips, Knowledge Expansion, ASK SME, and Event Highlights by subscribing to their monthly e-newsletter. Do not hesitate to consult their website or read their blog.

Tweet This Post

One of the main orientations is to build Urban Turtle into TFS (as opposed to integrate with). All our design decisions are made to bring as much value-added as possible while creating a seamless experience for existing TFS users and grow with TFS as Microsoft adds new features.

If you are interested about the details of the three releases we have made since the Visual Studio 2010 launch in April, please read the following posts:

1. April 30th – Urban Turtle 3.0 RTM is now available!
2. June 4th – Urban Turtle 3.1 now available!
3. July 8th – Urban Turtle 3.2 now available! – Support Visual Studio Scrum 1.0

We believe this orientation is what allows us to have a product that installs on the server in less than two minutes and gets a team to use it right away. We are very interested in hearing your stories and get your feedback about how we can further improve the experience.

Help us make our Urban Turtle a Chameleon

Also, our tight integration in the Web Access user interface makes the user feel at home and perceive TFS with new capabilities (as opposed to using an extra product). This is a big plus to have a smooth user adoption. We know that adopting scrum is already an interesting challenge; you do not need tools to get in your way but be a possible accelerator.

Again, give Urban Turtle a try and let us know how we succeeded in turning it into a Chameleon.

Tweet This Post

A not so far-fetched example

Let’s just imagine that we walk into DoMoreTech Inc. and we are confronted with 40 developers, 4 QAs, a few ivory tower architects and control hungry project managers. Not to mention a management team that believes taylorism is still the best way to create software.

The Java developers are totally separated from the back-end C developers. A test means starting up the Tomcat server and clicking away.  If you mention unit or automated tests, they look at you like a bunch of deers caught in the headlights. For the past 20 years or so, C developers have been masters of their domain and are very comfortable working within the three and half carpeted walls of their cubicles.  One of them even installed a makeshift cardboard roof to cut down on noise! Oh, yes! And everyone is working on at least 5 projects in parallel.

The QAs are on a mission: Embarrassing the developers during the weekly “team” meeting. To ensure that they reach their bug finding quotas, they withhold information that might help developers today.

Developers tremble when he appears at the elevator doors. Even the paying client with clearly define business needs folds under the pressure of the all mighty Architect.  The Architect has positioned BDUF as a critical process that must be respected for any and all projects to be successful. This well defined process is flawless and the Architect’s design is always perfect and final. If there’s a problem, it’s obviously due to the developer’s lack of maturity and experience.

Project managers and management are really happy that this “Agile thing” will help them do more with less. Since they are not part of the problem, only the technical teams need to improve the way they work.  Now that they have “purchased” Scrum, they have ADDITIONAL tracking tools to better control the situation and make better decisions for the teams.

Ok. Now what?

After a few days, when all these non-winning conditions are confirmed – What do you do as an Agile Coach? Jump in and hope for the best? Run away and never look back? Or maybe do away with the detailed diagnostic and simply leave a Hallmark card on the manager’s desk saying: “Sorry, but this ain’t gonna work”

Personally, I’ve seen watered down variations of the example above in different organizations and I’ve never turned down a client.  But to even hope for agile transition to succeed, the client does need to comply with two simple requirements:

Requirement 1

A pilot project (unless “Big Bang” implementation is considered). Neither a small and meaningless “test tube” project nor a do or die project. How about something just in the middle that involves external dependencies and creates value?

Requirement 2

We need a team. To quote a colleague of ours: “We don’t coach projects, we coach teams!”  And this team needs to be committed to one project. This Scrum team will be composed of a ScrumMaster, Product Owner and qualified individuals to create the solution.

Whether or not these requirements are met, a Mandate Charter is created in collaboration with the client to clearly define, among other things, the conditions of success (COS) of our initiative.  Taking time with the client to establish the conditions of success is a great collaborative activity and allows us to have those hard conversations and setting some facts straight.

If the basic requirements are met, the COS can be far reaching and beautiful things can happen!  If not, the COS might be superficial or even cosmetic in nature.  At this point, decisions need to be made.  Is the client willing to pay for cosmetic changes to his or her organization?  Does the client see value in these changes and is he or she able to sell ME on it?

It’s all about managing expectations.  A client can’t expect an agile coach to turn water in wine. But allow a coach to work with some quality basic ingredients and we just might end up with an award winning Cabernet Sauvignon.

Party on!

I am very aware of the previous debates on the need for an Agile Maturity Model (see the Other Useful Links at the end of this post). I actually agree with Esther Derby’s recent post …

How agile you are doesn’t matter. Whether you are 50 per cent agile, 90 per cent agile or agile through and through (what ever that means), doesn’t matter. What does matter is that your company is satisfying its customers, stakeholders, and employees. (Achieving Agility: Means to an End, or End in Itself)

But let’s face it, people like to know where they stand compared to others. Starting at a very young age, we have been raised and trained to compare our results to others in an attempt to reach the next level – whatever the next level may be.

We get into such comparison as:

• Are my grades better than Tommy’s?
• Can I run faster than Carl?
• Am I stronger than black belt Anna?
• Did I earn more frequent flyer miles than Frank?

It’s the same thing with Agile. People – managers and executives mostly – really have the need to know they are headed for the top of the maturity model. It may not make much sense but they have been raised and trained to measure, to compare, and to brag when comparing favorably or to adapt when comparison isn’t positive for them.

As I already stated, I agree with Esther when she says that it doesn’t really matter how Agile you are. What matters are the results. So along those lines, I believe it is important to associate the level of maturity and the related results which I believe exist and can be demonstrated.

Unfortunately, there isn’t much hard data to demonstrate that achieving a certain level of maturity provides x% of improved performance or y% cost reductions but most of us who have been implementing Agile within organizations would agree that that higher the maturity, the better the results. So it is based on these observations that I decided to present yet another Agile Maturity Model.

As recently reported by Forrester, Scrum being the most adopted Agile approach these days, the proposed maturity model heavily relies on the adoption of Scrum practices with a lesser consideration to other practices such as: Agile Modeling, Feature-driven development – FDD, Test-driven development – TDD, eXtreme Programming – XP, etc. By no mean I am rejecting or considering those other approaches non-important. I built this model mostly on Scrum because this is the comparison organizations are asking us to be evaluated on at this time.

The Agile Maturity Model

Level 1 – Team Level Maturity

At this level, team members have decided to adopt Scrum and/or software engineering practices without asking for approval from their manager. Some of the well known practices are used but without consistency.

Team

• A Scrum Master is in place
• The Team has adopted some of the Scrum practices and artifacts but may not use them consistently
• The process isn’t documented and tends to vary by project
• Agile practices have been self-taught
• Process is limited to the solution team
• The team doesn’t understanding the language used by the business representatives

Department

• Outside the team, almost nobody has heard or understand what Agile means
• Other teams are unaware or not interested in the approach used by the Agile team
• Mostly business as usual

Business

• Unaware or not interested in the approach used by the team
• Business as usual
• Complains that what the information technologies team delivers is not what is needed or asked for
• Misunderstanding of the language used for the development team

Project Managers

• Unaware or not interested in the approach used by the team
• Follow the traditional project management approach

Managers

• Unaware or not interested in the approach used by the team
• Business as usual

Results

• Team is slightly more productive
• Moral is slightly improved
• Much friction with project managers, people managers and the business as the team members try to teach people outside the team what Agile is and what it can do for them

Level 2 – Department Level Maturity

At this level, the practices adopted by the team members have started to be imitated by other teams within the software development department. Some of the managers have noticed the positive results of adopting the Agile approach and are tempted to replicate what they observed.

Team

• A Scrum Master is in place
• Some of the teams have adopted some of the Scrum practices and artifacts and are starting to use them consistently
• Consistency across the teams is uneven and mostly depends on the leadership and perseverance of a few individuals
• Some of the process is documented but it tends to vary by team
• Agile practices have been self-taught or a coach was hired to help the team launch their initiative
• Process is limited to the department

Department

• Mostly business as usual
• Agile is sometime discussed in departmental meetings with some interest from people outside the team immediately impacted
• An increasing number of teams are adopting Agile practices

Business

• A business analyst acts as the proxy for the business representative
• Unaware or not interested in the approach used by the team
• Collaboration between the development team and the business side remains mostly unchanged except maybe for increased interaction between the 2 groups
• Business decision are still mostly made by business analysts or architects

Project Managers

• Starting to be aware of the new practices used by some of the teams
• Mostly resistant to change since they are lacking information about the new process
• Follow the traditional project management approach
• Do not consider the Agile approach to be very solid for large scale projects

Managers

• Unaware or not interested in the approach used by the team
• Business as usual

Results

• Teams that have adopted the Agile approach are slightly more productive
• Moral is improving
• Productivity varies from one team to the next
• Some teams’ productivity is decreasing since they have hit important hurdles
• Some teams have abandoned the new approach and have gone back to their traditional approach
• Some friction between the development and the business teams in light of the new approach

Level 3 – Business Level Maturity

At this level, the solution teams have integrated the business people in the model. Collaboration (and trust) has increased and a partnership relationship is increasing.

Team

• Scrum Masters are in place
• The 3 Scrum roles are well understood and respected
• If there is more than 1 Scrum team, a Scrum of Scrum has been put in place
• External help has been used to achieve this level of maturity
• Team members are attending Agile conferences

Department

• There is confusion around the roles of: business analyst, architect, database administrators and project managers
• The process is documented and tends to be consistent across projects
• External help has been used to properly implement the Agile practices

Business

• A Product Owner is clearly identified and may be dedicated to their project
• The concept of incremental and iterative development is gaining more acceptance from the business representatives
• Process is slowly expanding within the business side
• Product Owners bring some of their colleagues to end-of-sprint demonstrations

Project Managers

• Starting to be aware of the new practices used by some of the teams
• Mostly resistant to change since they are lacking information about the new process
• Follow the traditional project management approach
• Do not consider the Agile approach to be very solid for large scale projects

Managers

• Awareness is increasing at the director level within IT and Business of the new Agile approach
• Many assumptions and misunderstanding remain
• A strong evangelist is in place to promote the new approach and bring together the IT and business side of the organization

Results

• Project teams using the Agile approach are more productive
• Moral of the people using Agile is much higher than those outside the Agile teams
• Some friction with project managers and people managers remain where most people tend to fall back to their traditional paradigms

Level 4 – Project Management Level Maturity

At this level, the project management approach is modified to include some of the Scrum practices. Although the department still mostly relies on the traditional PMBOK recommendations, Scrum has been integrated in the project management approach.

Team

• There is a clear segmentation between the role of the Scrum Master and that of the project manager
• If there is more than 1 Scrum team, a Scrum of Scrum has been put in place
• Interference with the team’s activities is almost eliminated
• The team is autonomous and the Scrum rituals and artifacts are respected and standardized

Department

• The department has adopted many of the Scrum practices and artifacts and are using them consistently
• Much of the confusion around the roles of: business analyst, architect, database administrators and project managers have been eliminated
• The process is documented and is consistent across projects
• External help has been used to properly implement the Agile practices

Business

• Product Owners are clearly identified and are dedicated to their project
• The project manager is well accepted and is part of the Product Owner team
• The concept of incremental and iterative development is fully accepted from the business representatives
• Process is expanding to the business side

Project Managers

• Projects managers are fully aware of the new practices used by the teams
• Resistance to change has been replaced with adaptation of the traditional approach to include a more Agile approach
• Agile is accepted as a solid approach for large scale projects

Managers

• Awareness of the new Agile approach is increasing at director level and above within the IT, Business, and Project Management organizations
• Some assumptions and misunderstanding remain for managers
• Training initiatives have begun for management and attendance is high
• A strong evangelist is in place at the management / executive level to promote the new approach

Results

• Project teams using the Agile approach are more productive
• Moral of the people using Agile is much higher than those outside the Agile teams
• Friction between traditional roles are being handled

Level 5 – Management Level Maturity

At this level, managers have adapted their management style to support an Agile organization. Organizational structures and reporting mechanisms are better adapted for collaboration and improved for increased performance.

Team

• Scrum Masters are in place
• The 3 Scrum roles are well understood and respected
• If there is more than 1 Scrum team, a Scrum of Scrum has been put in place
• External help has been used to achieve this level of maturity
• Team members are attending Agile conferences

Department

• The department has adopted many of the Scrum practices and artifacts and are using them consistently
• There is no confusion around the various roles surrounding the projects
• The process is documented and is consistent across projects

Business

• Product Owners are clearly identified and are dedicated to their project
• The project manager is well accepted and is part of the Product Owner team
• The concept of incremental and iterative development is fully accepted from the business representatives
• Process is expanding to the management level of the organization

Project Managers

• Projects managers are fully aware of the new practices used by the teams
• The traditional project management approach has been adapted to include a more Agile approach
• Agile is accepted as a solid approach for large scale projects
• Review the best practices to adapt to changing realities

Managers

• Have fully transferred the authority and responsibility to the teams to allow them to do their job properly
• Avoid interference and micromanagement
• Promote collaboration and teamwork
• Support continuous learning and do not systematically penalize failures
• Adapt their management style to the context of their team

Results

• The various projects using Scrum are more productive than those using a traditional approach
• Moral is high all around
• Friction around the new approach has disappeared
• Strong collaboration between all parties involved
• Organization is able to quickly react to changes in its environment
• Management is considering implementing Agile to projects that do not require software development

Level 6 – Corporate-wide Level Maturity

Utopia or the nirvana? At this level, the entire organization – the people, the processes and the tools are aligned with the Agile principles and values. As I haven’t had the opportunity to witness such an organization (yet), I am unable to describe the criteria to be used to qualify for this level.

Other useful Links

• The Agile Maturity Model (AMM) posted on April 1, 2010.
• Does Agile Need Its Own Process Maturity Model? posted on June 1, 2009.
• Scott Ambler Revisits Agile Process Maturity Models posted on April 27, 2009.
• Agile CMMI: Complimentary or Oxymoronic? posted on December 19, 2008.
• The Agile Maturity Model posted on August 2, 2008.
• Does the Agile Community Need a Maturity Model? posted on October 16, 2007.
• An “Agile Maturity Model? posted on June 7, 2006.

You might be interested in these related posts:

1. Gartner’s “The Current State of Agile Method Adoption”
2. Agile Transition – What about the teams outside the transition?
3. Secret Revealed! Guaranteed Success for your Agile Transition

Support for Visual Studio Scrum 1.0
Urban Turtle 3.2 fully supports the new Scrum template from Microsoft from the get-go. This post introduces the new features that have been developed for the template, but I strongly recommend that you take some time to read this previous entry to understand the reasoning behind them. Most of these features can be configured to work with other process templates.

New Feature: Approval
Product Owners can now approve PBIs with a single click when looking at their backlog in the Planning Board.

New Feature: Commitment
We made it possible to commit to PBIs contained in a sprint with a single click, again from the Planning Board.

New Feature: Sprint Details
We’ve made it easy to create and access the Sprint work item through the Sprint Details button in the planning board’s iteration list.

New Feature: Favorite iterations and areas
As Dom mentionned before, we have been looking at ways to reduce the number of iterations and areas visible at any time. We’ve come up with a great idea which actually is not our idea at all. I mean, favorites is anything but new in software! Basically, you can now easily switch between viewing all iterations/areas where you can flag some of them as favorites, and then hop back to a view where only favorite iterations/areas are displayed. This effectively reduces the number of work items displayed at once and helps you focus on the task at hand.

Once again, we recommend that everyone upgrades to this latest version and we are eagerly awaiting your feedback. Let us know what you think in our community-powered support site!

Tweet This Post

As Agile Coaches, we aim to be efficient. We analyze the situation around us, we ask questions, we experiment, we share our thoughts and observations, we make suggestions and recommendations. We try to be helpful.

Are we always efficient in the way we ask our questions? Could we ask our questions differently for better impact?

Below is a list of qualities associated with Powerful Questions taken from the reading material of the certification program I’m currently undertaking.

• Clarity
• Brevity
• Relevance
• Direct
• Single Subject
• Positive expression
• Allow silence for the response

To be powerful, the questions should also have an impact. To be impactful, the question should aim at:

• Personal issues and remain contextual;
• Motivation behind the actions;
• Consequences of the actions.

And include the question “what else?”.

What we are looking for in the levels of information provided is:

• Facts
• Emotions
• Opinions

Finally, to be truly powerful, the questions should take the person out of his comfort zone in order to explore new horizons. Questions such as the following are usually very helpful:

• What would happen if …?
• With hindsight, what can you see?
• If you were an expert in this field, what would you do?
• If you had a magic wand, what would you do?

Formulating a question isn’t always easy but to be an impactful coach, properly asking the question is critical. Hopefully, these few tips can help you become a better coach.

You might be interested in these related posts:

1. What Is Coaching? And Other Relevant Questions
2. It's Sunday and I can't wait to go to work tomorrow
3. On my way to coaching certification

Sprint planning

L’équipe commence à être efficace durant la planification de l’itération, j’ai moins à intervenir! En tant que tel, je trouve que c’est une bonne chose. Ca me fait penser que mes interventions précédentes ont porté fruit et que l’équipe devient indépendante. Du moins pour cette cérémonie…

Backlog maintenance

L’efficacité de l’équipe se propage aux autres cérémonies. Cette séance se déroule avec très peu d’interventions de ma part. Les membres de l’équipe discutent entre eux du contenu des stories, posent des questions au PO et s’entendent généralement, en 2 tours de planning poker, sur le pointage à mettre sur une carte. On pourrait penser que s’est une équipe formée depuis longtemps et qu’ils sont tous habitué de travailler ensemble.

Il reste un point qui risque de devenir problématique, le backlog n’est pas très garni. Ce qui fait qu’il n’y a pas de stories, ou même d’epics, d’avance pour les prochaines itérations. L’engagement de l’équipe pour la prochaine itération risque d’être limité par le contenu du backlog. Il y a de la sensibilisation à faire auprès du PO. À suivre…

Sprint review

Une autre review qui va bien! Cette fois, par contre, il n’y a que le patron du PO qui est présent, l’utilisateur n’est pas là. Ca n’empêche pas à l’équipe de recueillir tous les points auxquels elle était engagée. La patron pose quelques questions et semble satisfait. C’est une review express qui se déroule rapidement, mais ca n’empêche pas que tout le monde est content du résultat.

Sprint retro

Les membres de l’équipe s’attendaient à la formule des 2 sprints précédents; identifier les points forts et les points à améliorer. Un membre me demande en blague « C’est maintenant qu’on chiale ? ». Je lui réponds avec sourire que non, ce n’est pas aujourd’hui! J’ai autre chose de prévu. J’ai constaté que les membres de l’équipe travaillent beaucoup selon leurs spécialités respectives. Je pense que ca a un impact sur le déroulement des itérations, certains membres sont un goulot au début de l’itération et d’autres vers la fin. C’est un signe! Je questionne l’équipe sur le potentiel de travail de façon multidisciplinaire. Ils semblent s’opposer à ma proposition. Je comprends par leur réaction qu’ils ne sont pas contre, c’est qu’ils ne comprennent pas la même chose que moi. Ils entendent que tous les membres de l’équipe atteignent un même niveau d’expertise dans tous les domaines et que chacun peu faire le même travail au même niveau d’efficacité et de qualité. Ouf, je comprends qu’ils s’opposent. Ce que j’entends est plutôt que chacun peut faire du travail qui relève d’une autre discipline, ceci pour s’assurer que l’itération avance bien lorsque qu’un spécialiste n’est pas disponible (avec la saison des vacances qui approchent, ca va rapidement devenir une réalité!).

L’équipe me trouve dur avec mes questions, ils suivent quand même bien l’exercice de rétro. Il faut un peu d’encouragements de ma part, mais les équipiers finissent pas adopter l’idée de travailler en paire interdisciplinaire pour mieux partager la connaissance. On verra à la prochaine rétro comment ils ont apprécié l’expérience.

• Where do we put the time for meetings?
• Do we need to have absolutely all tasks in the sprint backlog?
• When we are pairing, do we do time entries for each of us?
• When we plan, do we create tasks for all the available hours we have? (more on this in the post Sprint and Compelling Goals)

Vince came back home today only to be greeted by firetrucks and the local fire marshal. He was quickly relieved to learn that his brand new condo was not on fire. Unfortunately, for his neighbor Harry, the fire marshal was there expelling him from his own home until he got his mess together.

When Vince found Harry he was in a terrible state of mind. You see, 78 years old Harry had been collecting all the newspapers he could get his hands on ever since his wife had died at 52. 26 years of newspaper stacked up against the walls was too much and a suspicious neighbor made a phone call to the local fire department before Harry would turn his home into the biggest BBQ the city had ever seen. Harry had just lost his entire collection.

All this turmoil shook up Vince inside. When he came back to work Monday, he started thinking about all the mess that was accumulating in his own project.

He made the following list of all that was accumulating around him :
- The backlog had tons of duplicate bugs
- A ton of stories were planned for but not estimated
- The main domain classes of the application were starting to have more responsibilities than the companies C.E.O.
- Some of the controllers were getting bloated
- The code produced by the interns had not been peer reviewed for weeks
- The users documentation was dated by two revisions

….

Vince then went to see his Product Owner and told him about the issue. He was dumbfounded to learn this at first, but after a long discussion, he brought the team together, talked about what was most urgent and how much dealing with each issue would cost.

He then added the elements with the best return on the investment at the top of the backlog and chipped in where he could to help the team address these issues. Within a few months, the situation was very promising and the team was now bringing up issues all the time without the need for them to accumulate.

A year later, most of his fellow Product Owners and their teams were engulfed in crap that had accumulated sprint after sprint. Always planning to fix it later,they never ever did.

Meanwhile this team just glided through the problems at a steady pace and it seemed nothing could stop them in their tracks. For the team members, the project just felt like a train anybody would love to embark on. Their biggest pride, was that it was their own.

-Nicholas Lemay

For those of us who have been working with Agile for a while, the values, the principles, the approach, the methods and the practices are almost second nature but for those who start to enter the Agile world, the ramp up can be challenging – especially if you are looking at all of this from a management position.

After being asked by a few people “Where can I start if I would like to know more about Agile?”, I decided to put together this short list of reference material. There is also a good discussion happening on LinkedIn.

I am missing anything? Is there material you would recommend to managers?

What is Agile?

Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.

The term was coined in the year 2001 when the Agile Manifesto was formulated.

Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. (Agile software development – Wikipedia)

“Agile Development” is an umbrella term for several iterative and incremental software development methodologies. The most popular agile methodologies include Extreme Programming (XP), Scrum, Crystal, Dynamic Systems Development Method (DSDM), Lean Development, and Feature-Driven Development (FDD).

While each of the agile methods is unique in its specific approach, they all share a common vision and core values (see the Agile Manifesto). They all fundamentally incorporate iteration and the continuous feedback that it provides to successively refine and deliver a software system. They all involve continuous planning, continuous testing, continuous integration, and other forms of continuous evolution of both the project and the software. They are all lightweight (especially compared to traditional waterfall-style processes), and inherently adaptable. As important, they all focus on empowering people to collaborate and make decisions together quickly and effectively. (Agile 101: What is Agile Development? | VersionOne)

Just what is agile software development? In 2001, a group of methodologists got together to agree on a common set of guiding principles around effective software development. Rather than summarize their agreements here, I’ll point you to their “agile manifesto”.

From a pure definition standpoint, agile is a conceptual framework generally centered on iterative and incremental delivery of working software, driven by the customer. The iterative part suggests that we are repeating, or iterating, a complete lifecycle of development over a short, fixed span of time. With each of these iterations, we ship some working subset, or increment, of features. (A Brief Introduction to Agile — Developer.com)

What is Scrum?

Scrum is an agile approach to software development. Rather than a full process or methodology, it is a framework. So instead of providing complete, detailed descriptions of how everything is to be done on the project, much is left up to the team. This is done because the team will know best how to solve its problem. (Introduction to Scrum – An Agile Process)

Scrum is an iterative, incremental framework for project management and agile software development. Although the word is not an acronym, some companies implementing the process have been known to spell it with capital letters as SCRUM. This may be due to one of Ken Schwaber’s early papers, which capitalized SCRUM in the title.

Although Scrum was intended for management of software development projects, it can be used to run software maintenance teams, or as a general project/program management approach. (Scrum (development) – Wikipedia)

Scrum is an agile framework for completing complex projects. Scrum originally was formalized for software development projects, but works well for any complex, innovative scope of work. The possibilities are endless. (Scrum Alliance -What Is Scrum?)

The Scrum Roles

Scrum has three roles: Product Owner, ScrumMaster, and Team. (Scrum Alliance -Scrum Roles)

Tips for an Agile Transition

Organizational Impact of an Agile Transition

When development teams adopt agile practices, product management is often caught off guard by the amount of work added to their already overflowing plate. Agile calls for new product management skills and traditional staffing models do not typically accommodate the new product owner role. Given that most product managers are already overworked, how can they manage these new activities to derive more value from software projects and products? (InfoQ: How Product Management Must Change to Enable the Agile Enterprise)

Agile methodologies are helping software organizations stay competitive by delivering products more frequently and with significantly higher quality. Making the switch to agile development also challenges traditional notions of project management, introducing new ways of managing time, cost and scope. Learn how to successfully manage agile projects with the resources below. (Agile White Paper: The Agile Project Manager | VersionOne)

When an organization starts to explore Scrum, there’s often an uncomfortable moment early on when someone points out that the role of “manager” seems to be missing entirely. “Well I guess we’ll have to just get rid of ‘em all!” wisecracks one of the developers, and all the managers in the room shift uncomfortably in their seats. (Scrum Alliance -Manager 2.0: The Role of the Manager in Scrum)

About Agile Coaching

Gartner’s analysts (Thomas Murphy and David Norton) predict that by 2012 “agile development methods will be utilized in 80% of all software development projects”. The authors explain that although Scrum will continue gaining in popularity over the coming years, organizations will not be successful in their transition unless they move toward a team-focused culture (Gartner Predicts 2010: Agile and Cloud Impact Application Development Directions | Analytical-Mind)

In their recently released study “Agile Development: Mainstream Adoption Has Changed Agility“, Forrester reports that “35% of respondents stated that Agile most closely reflects their development process”. The report is based on Forrester’s/Dr. Dobbs Global Developer Technographics Survey, Q3, 2009, which surveyed 1298 application development professionals. (Forrester Reports “Agile Development: Mainstream Adoption Has Changed Agility” | Analytical-Mind)

Recommended Blogs

Recommended Books

You might be interested in these related posts:

1. Scrum Role: Scrum Master
2. What is Scrum?
3. Scrum Role: The Scrum Team

In a large scale transition similar to the one we have undertaken a few months ago, it is difficult (and maybe impossible) to transition all the teams / departments at once. Similar to the prioritization of the product backlog, we have selected a handful of projects to launch immediately. Unfortunately, this means that many (many more) projects will not begin their transition for a while since the organization we work with has decided that coaches are required to help them succeed.

As such, we have decided to implement a strategy for those “out of transition” teams. Below is the approach we selected in order to make the transition successful without negatively impacting the performance (and the workload) of those directly involved in the transition. Based on our experience, we felt it was important to have a strategy (albeit minimal) to support other projects to be implemented using an Agile approach.

The reasons why it is important to have a strategy for those “out of transition” projects are as follows:

• To maintain a unifying vision of what we are trying to accomplish with Agile;
• To maximize our efforts in the development and selection of tools supporting Agile;
• Not to ‘abandon’ the projects that were not deemed highest priority;
• For other projects to be executed successfully in an Agile mode even if they are not part of the intial selection.

Therefore, we suggested having a reduced service catalog for the “out of transition” projects. Examples of services that can be offered are:

• Training courses offered to the selected projects could also be attended by “out of transition” participants;
• A simple audit of the “out of transition” projects’ practices and high level recommendations for improvement;
• Limited support;
• Access to the corporate wiki for information, knowledge sharing and best practices.

So far, the recommendation has been well received by the “out of transition” projects. In the months to come, we will be able to determine if we made the right decision.

You might be interested in these related posts:

1. What consultants don’t tell you before you begin an agile transition – Part 4: Why a coach is useful
2. What consultants don’t tell you before you begin an agile transition – Part 2: Impact on some of the traditional roles
3. What consultants don’t tell you before you begin an agile transition – Part 1: Impact on the organization

Supporting MSF Agile 5.0
Urban Turtle 3.0 shipped with built-in support for MSF Agile 5.0 out of the box. We obviously assume most people using Urban Turtle have chosen this template because of this build in support. This template made it a challenge for us to implement a three-column task board because work items only have one Active state. Items are either active or they’re resolved or closed. Back then, we decided to use the AssignedTo field to determine where the work item should appear when it is active. An unassigned and active task should show up in the To Do column while an assigned and still active task would appear in the In Progress column. It made sense to us as we’re Scrum practitioners and we believe tasks should be unassigned until someone actually starts working on them.

While implementing support for MSF Agile 5.0, we made sure to externalize everything that seemed template-specific, like the state mapping for the task board columns or the stack rank (backlog priority) field. We then claimed to be template-independent, but some assumptions would later turn out to be wrong.

False Assumptions
When Microsoft announced the beta release of their TFS Scrum 1.0 process template, we figured we could quickly create a new mapping file to add support for it. We began analyzing the new template and we realized we couldn’t do it without touching the code base. Honestly, it would have been as easy as we thought but the decision by the Microsoft team, to stay true to the Scrum terminology, turned out to be a blocker for us.

When working on the initial release of  Urban Turtle 3.0, we made the assumption that system fields such as Id, State and AssignedTo would not be configurable. That was a mistake. Microsoft decided not to use the AssignedTo field used to determine who’s working on a task and opt to go with a field named OwnedBy. The vocabulary makes tons of sense but the change made it impossible to use Urban Turtle as it was with the new template.

When basic is not enough
This change was all that was required to build basic support for TFS Scrum with a new mapping file. We could easily define what fields should show up where, what states should appear in the task board columns, etc. We built this basic support within a single day, including refactoring the application code to support configuration for the AssignedTo field. However, we found such basic support to be somewhat lacking.

We started testing the application with the new template and we quickly realized that the state mappings pretty much made the task board impossible to use with Product Backlog Items and Bugs. These two types have the following states: New, Approved, Committed, Done and Removed. We ignored the latter and configured the first three to show up in both the To Do and In Progress columns and mapped the Done state to the Done column. However, the transitions configured between the three active states made us realize that only the Committed state actually made sense in the task board.

We thought that choosing to hide new and approved work items from the task board would cause confusion when users would look at their task board and search for missing items. That’s when we decided to implement two new features to facilitate the state transitions.

New Feature: Approval
Product Owners can now approve PBIs with a single click when looking at their backlog in the Planning Board. This feature can be configured as a state transition in the mapping file and could be used with other process templates. In the case of the TFS Scrum template, we’ve mapped the New -> Approved transitions for PBIs and Bugs to the Approval feature.

New Feature: Commitment
Approved work items still don’t show up in the task board. The task board is used to track work being done during a sprint. The team should never be working on something they haven’t committed to yet. It makes perfect sense with regards to Scrum. We could have implemented this feature the same way we did with the Approval, but while a Product Owner usually approves items one by one, a team commits to a set of PBIs. For that reason, we decided to make this a batch process. We therefore made it possible to commit to PBIs contained in a sprint with a single click, again from the Planning Board. This feature can be customized by defining the state transition that should be triggered when this feature is used.

New Feature: Sprint Details
The last thing we wanted to add to our initial support of  TFS Scrum was a way to manage the new Sprint work item type. This type was defined as a way to work around limitations in TFS regarding Iteration nodes metadata. It defines begin and end dates for the sprint, as well as sprint goal and retrospective details. We’ve made it easy to create and access this work item through the Sprint Details button in the planning board’s iteration list. This button only appears when the Sprint work item type is defined in the mapping, another customizable option.

Beta Release
It has been a mere two weeks since the release of  TFS Scrum 1.0 Beta (Visual Studio Scrum) and we are ready to give you a taste of the support we’ve built for it in Urban Turtle with the beta release of Urban Turtle 3.2. We hope that you will take the time to give it a try and we are looking forward to hearing from you  as we strive to improve the Turtle and accomplish our mission to enable your team to create kick-ass software – fast and sustainably.

Tweet This Post

In December 09, a colleague of ours was a tad bit envious of a great initiative leaded by Laurent Cobos. Laurent, through a collaborative effort with the Pyxis developer community created the Pyxis Developer’s Charter.

Seeing the rallying effect of the Developer’s Charter, we attempted to launch a similar initiative for Agile Coaches, but we had limited success. Coaches being in high demand these days, we had less time to invest in developing a strong and honest charter that other coaches could easily identify to.

We did however identify some conditions of success:

- The language must be business compatible

- Must show that the coach is accountable to the client

- Must show that our client is equally accountable to the coach

- Can included specific practices

- What else?

And through our internal wiki and a couple of meetings, we came up with this:

As an Agile Coach, I commit to the team and its organization to…

• Never apply recipes
• Respect your distinct culture
• Help you challenge your current culture, principles and practices
• Let you learn from your mistakes
• Not let you make irrecoverable mistakes
• Put in place an empirical process that allows learning
• Allow you to evolve within that empirical process
• Allow the process itself to evolve
• Have to courage to say No
• Guaranty bug free software
  
• Telling you what you must hear and not what you would like to hear.
• Not inflict help
• Help you expose the value you create
• Help you expose non-valuable activities
• Help you identify obstacles
• Help you identify solutions
• Help you to communicate efficiently
• Be continuously aware that I can be profoundly influenced by the non-Agile surroundings, immediate context and personalities. (Inspired from The Tipping Point)

• Stay true to the Agile Manifesto

What would you add, change or simply remove?

What makes uncomfortable?

Which statement makes you stand-up and cheer?!

What would be your preferred format?

Would you sign this Charter?

All members of Team Urban Turtle are great fans of the Montreal Canadiens and we were quite sad to hear the news today that Halak had been traded to the Blues. While working on the past few releases, we fed on the adrenaline rush generated by Halak’s breathtaking performance during the playoffs. We’re disappointed to see him go but we wish him the best of luck with his new team.

Tweet This Post

Sprint planning

J’apprends que le patron du PO a vraiment apprécié de participer à la review de la semaine dernière. Il veut être invité encore à la fin du sprint présent. C’est une bonne nouvelle!

Pour débuter, j’explique à l’équipe qu’à la dernière itération ils ont réussi à réaliser 4 points de story. En principe, ils devraient aussi être capable de réaliser 4 points à cette itération. À la review de l’itération 1, une story a été refusée par le PO. Je me souviens qu’ils étaient convaincus qu’il ne restait que peu de temps à faire pour la compléter. Alors, l’équipe pourrait s’engager à faire 6 points. Aahhhh! Soulagement collectif. Ils n’avaient pas bien compris qu’ils pouvaient s’engager à plus. L’équipe regarde le backlog, est confiante et s’engage à réaliser 10 points. J’aime ça les équipes optimistes!!

Backlog maintenance

Avant de débuter la séance, nous avons une petite discussion à propos d’une situation « particulière ». Le patron du PO ne peut pas être présent pour la review et demande à l’équipe de faire la présentation à un autre moment pour qu’il puisse y assister. Après discussion au sein de l’équipe, les membres proposent d’échanger les séances de planning et de review. Ai-je bien compris ? L’équipe veut s’engager sur le prochain sprint sans connaître le résultat du sprint actuel ? Il semble que j’avais bien compris… L’équipe justifie qu’elle se sent en confiance de réussir l’engagement et qu’il n’y aura pas de problème. Même si l’équipe ne réussi pas, les membres considèrent l’impact mineur. J’ai fait part de mes réserves, l’équipe connait les conséquences potentielles. Je leur laisse maintenant la décision.

Le backlog n’est pas très garni, ça a comme conséquence que peu d’items sont estimés. Nous avons prévu deux séances de backlog maintenance pour cette itération, pour permettre au PO de rédiger d’autres stories. Pour la séance de ce matin, l’équipe a réussi à estimer 4 stories. Ça ne semble pas beaucoup, mais les discussions entourant les stories étaient intéressantes. Elles ont permis de faire diviser une story en deux, afin de réduire la complexité, de clarifier des éléments et faire ressortir des points que le PO doit éclaircir pour la prochaine séance.

Sprint review

Comme au sprint 1, des intervenants ont assisté à la review. Il y a 3 stories à présenter et le résultat d’un spike. Le PO a pris contrôle du clavier dès le début de la séance. Première story à démontrer; le PO commence à faire le tour des écrans pour valider l’information transmises. Il ressort tranquillement qu’il n’est pas prêt pour la review, il cherche un peu quelles données utiliser et où sont certaines informations. Je prends note que je devrai un peu mieux accompagner le PO pour qu’il se prépare pour la review. Les membres de l’équipe semblent aussi l’avoir remarqué. Je ne serai pas seul à en parler au PO…

Sprint retro

Pour cette deuxième rétro je préfère rester au niveau des processus. Alors je garde une formule assez traditionnelle de faire ressortir les points forts et points à améliorer. J’oriente par contre la discussion autour des cérémonies de Scrum; planning, backlog maintenance, review, retro et le déroulement général des itérations. Des bons points ressortent sur les différentes cérémonies. À l’opposé, l’équipe trouve que la mêlée quotidienne est inefficace; les membres de l’équipe communiquent beaucoup et se synchronisent près du tableau de tâches à chaque matin avant l’heure de la mêlée, alors ils ont le sentiment de se répéter. Pourtant, à quelques reprises durant la mêlée quotidienne, d’après la réaction de certains autres membres face à la réponse à « Qu’as-tu accompli hier? », j’ai senti que de l’information nouvelle circulait dans le mêlée. Elle n’est peut-être pas efficace, mais elle semble utile!

Following an earlier post on this topic and based on the increasing popularity of Agile Leadership, I have revisited my previous model with the experience we are gaining with the transitioning a large Canadian financial institution. Although the transition is still underway, our increasing experience is allowing us to improve the model.

The fundamental objective of this model remains to increase return on investment (ROI) and employee satisfaction / motivation within the project teams while applying the 4 Agile values and 12 underlying principles.

LEADERSHIP

Leadership is stated as the “process of social influence in which one person can enlist the aid and support of others in the accomplishment of a common task” – Wikipedia.

Objectives setting and performance management

Goal setting involves establishing specific, measurable and time-targeted objectives - Wikipedia.

Performance management includes activities to ensure that goals are consistently being met in an effective and efficient manner - Wikipedia.

This dimension of the model focuses on:

• Using a clearly defined vision, identifying and communicating clear objectives so that people know what to do;
• Aligning the goals of the team members amongst themselves and with the focus on delivering business value to the organization;
• Providing frequent feedback to employees so they can adapt their performance accordingly;
• Evaluating the performance level of the project team, in addition to individual performance.

Management and leadership style

Management in all business areas and organizational activities are the acts of getting people together to accomplish desired goals and objectives - Wikipedia.

Leadership style refers to a leader’s behaviour. It is the result of the philosophy, personality and experience of the leader - Wikipedia.

This dimension of the model focuses on:

• Switching from a traditional “command and control” to a “servant leadership” style;
• Abandoning an autocratic and prescriptive style to make room for autonomy and emergence;
• Allowing space for teams to become autonomous;
• Adopting a situational leadership style based on the maturity level of the team;
• Evaluating the end results rather than the means used to implement the plan;
• Assisting the team in addressing its needs;
• Providing the necessary support to develop individuals;
• Giving people the right to make mistakes;
• Facilitating collaboration.

ENVIRONMENT

Surroundings are the area around a given physical or geographical point or place - Wikipedia.

Work environment and organizational culture

Organizational culture is an idea in the field of Organizational studies and management which describes the psychology, attitudes, experiences, beliefs and values (personal and cultural values) of an organization - Wikipedia.

This dimension of the model focuses on:

• Establishing a favorable work environment to support the success of an Agile project;
• Providing open and collaborative spaces;
• Providing simple tools such as whiteboards;
• Reserving small enclosed meeting rooms;
• Using furniture that can easily be moved;
• Providing hardware and software that reduces the costs and initial delays to start-up projects.

PROJECT TEAM

A project team is a team whose members usually belong to different groups, functions and are assigned to activities for the same project - Wikipedia.

Autonomy and accountability

Autonomy is a concept found in moral, political, and bioethical philosophy. Within these contexts, it refers to the capacity of a rational individual to make an informed, un-coerced decision - Wikipedia.

Accountability is a concept in ethics and governance with several meanings. It is often used synonymously with such concepts as responsibility,answerability, blameworthiness, liability, and other terms associated with the expectation of account-giving - Wikipedia.

This dimension of the model focuses on:

• Giving authority to the team to allow it to do its job properly;
• Transferring the authority and responsibility to the team:
  • The way to do things and organize work (the HOW?)
  • On the allocation of tasks and ideally on the composition of the team (the WHO?)
  • On the estimation of effort required to complete tasks (the HOW MUCH?)
  • It can even be the place (the WHERE?) and the work hours (the WHEN?)
• Avoiding interference and micro-management;
• Giving autonomy to individuals to make them accountable;
• Creating teams of reasonable size to facilitate collaboration and communication;
• Letting people who are closest to the action make the final decisions;
• Providing the necessary support when the team requests it.

Collaboration and teamwork

Collaboration is a recursive process where two or more people or organizations work together in an intersection of common goals - Wikipedia.

Teamwork is work performed by a team - Wikipedia.

This dimension of the model focuses on:

• Promoting collaboration and teamwork;
• Maintaining a climate of trust and respect within the team;
• Developing the concept of compromise;
• Taking a position of cooperation and negotiation rather than honoring contracts;
• Encouraging discussion and debate of ideas in order to bring out the best decisions.

Communication and knowledge sharing

Communication is a process of transferring information from one entity to another - Wikipedia.

Knowledge sharing is an activity through which knowledge (i.e. information, skills, or expertise) is exchanged among people, friends, or members of a family, a community or an organization - Wikipedia.

This dimension of the model focuses on:

• Encouraging the use of face-to-face communication;
• Providing opportunities for people to share information and knowledge;
• Establishing communities of practice to promote the exchange of knowledge;
• Making relevant information visible to all participants.

Skills and Professional Development

A skill is the learned capacity to carry out pre-determined results often with the minimum outlay of time, energy, or both - Wikipedia.

Professional development refers to skills and knowledge attained for both personal development and career advancement - Wikipedia.

This dimension of the model focuses on:

• Ensuring that participants have the skills required to successfully execute their tasks;
• Promoting training and development when the skills are not adequate.

Continuous improvement and organizational learning

Continuous Improvement Process is an ongoing effort to improve products, services or processes. These efforts can seek “incremental” improvement over time or “breakthrough” improvement all at once - Wikipedia.

Organizational learning is an area of knowledge within organizational theory that studies models and theories about the way an organization learns and adapts - Wikipedia.

This dimension of the model focuses on:

• Allowing the team to question frequently its good (and bad) actions in order to improve;
• Not systematically penalizing failures;
• Addressing recurrent problems;
• Documenting and make visible the organizational barriers;
• Reviewing the best practices to adapt to changing realities.

Processes and Tools

Process or processing typically describes the act of taking something through an established and usually routine set of procedures to convert it from one form to another, as a manufacturing or administrative procedure, such as processing milk into cheese, or processing paperwork to grant a mortgage loan, or converting computer data from one form to another - Wikipedia.

A tool is a device that is necessary to, or expedites, a task - Wikipedia.

This dimension of the model focuses on:

• Letting the best processes and tools emerging from the team members;
• Allowing the team to choose its tools and adapting its processes to maximize performance;
• Disseminating best practices to other groups;
• Ensuring that the team has set its own rules of operation.

I am building and using this framework to help dissect the key components of Agile Leadership in order to help explain it to people managers and team members. Based on your experience, are there any dimensions missing?

You might be interested in these related posts:

1. The 5 Dimensions of Leadership in an Agile Context
2. The 7 Dimensions of an Agile Project Team
3. Agile Leadership (Agile Management) – part II

I have been developing software in Scrum for a long time and coaching many teams and organizations adopting Scrum. Therefore, I have been exposed to a lot of situations and feel I have integrated the fundamentals and the theoretical foundations of Scrum.

My general feeling, which you will see expressed throughout this blog post is that the Agile community is falling into the trap of looking for optimizations everywhere and is losing sight of some fundamentals about complexity, creativity, teamwork and commitments.

When I first heard about Kanban, I was intrigued and read about it and even applied it in some situations I felt it could be helpful. There are a couple of nice things that Kanban brings to the table but I also think that it breaks some fundamental things that make Scrum work.

Within sprints, Scrum suggests a simple workflow with sprint backlog items going from ‘To Do’ to ‘In Progress’ to ‘Done’. I have certainly seen some Scrum teams have way too much work ‘In Progress’ and using Kanban techniques to limit the amount of work in progress can certainly help. I also do not think it is necessarily a bad idea that a mature team establishes a more defined workflow and uses Kanban techniques to control its flow of work but going too far (I have seen a Kanban board with 10 columns corresponding to stories’ statuses) in that direction will reduce the possibilities of emergence that creates true performance in self-managing, multidisciplinary teams.

Getting to the actual debate of having sprints or not. Some Scrum proponents say that not having sprints may be problematic because the team needs to hold regular retrospectives to accelerate learning. While I do agree that holding regular retrospectives is absolutely essential, I think that a Kanban team could do regular retrospectives while not completely applying sprints.

I think Ken Schwaber has a much stronger point. In his Waterfall, Lean/Kanban, and Scrum blog post, he presents sprints from the point of view of the complexity theory.

A container is a closed space where things can get done, regardless of the overall complexity of the problem. In the case of Scrum, a container is a Sprint, an iteration. We put people with all the skills needed to solve the problem in the container. We put the highest value problems to be solved into the container. Then we protect the container from any outside disturbances while the people attempt to bring the problem to a solution. We control the container by time-boxing the length of time that we allow the problem to be worked on. We let the people select problems of a size that can be brought to fruition during the time-box. At the end of the time-box, we open the container and inspect the results. We then reset the container (adaptation) for the next time-box. By frequently re-planning and shifting our work, we are able to optimize value.

Vincent also brings an interesting viewpoint in his recent post Scrum is not about project management
.

While explaining the notion of container, Ken mentions above: “We put the highest value problems to be solved into the container.” I would like to push this a little further and relate it to planning and commitment. I have always insisted in my Scrum classes that a successful sprint planning is not about delivering a sprint backlog, it is first and foremost about having a team committed toward a goal that is compelling for them as a whole including the ScrumMaster and Product Owner. I believe, this is one of the fundamentals to create creative hyper-performing, self-managing teams that can sustain.

I have felt during the last few years that as a community we are putting too much focus on the concept of velocity and, therefore, many teams are un-passionately identifying their commitment based on their velocity and do not get to the true nature of what it means to be committed toward a compelling goal.

Before you throw tomatoes at me, I am not saying that measuring velocity is useless. I am saying that while it is useful for a team to measure and be aware of its velocity, I think we let it drive too much the commitment decisions of the team. Some tools are in my opinion putting too much emphasis on using velocity to drive the sprint planning process.

This belief of the importance of being committed toward a compelling goal was reinforced recently while reading the following book: The three laws of performance. Here are the three laws presented in the book:

1. How people perform correlates to how situations occur to them.
2. How a situation occurs arises in language.
3. Future-based language transforms how situation occurs to people.

I will not try to summarize the book here. I thought it is useful to mention this reference because I think it links the importance of creating an environment in planning sessions that enables the team to choose a goal that is compelling for them to some fundamentals of human beings.

In summary, I suggest to use sprints as defined in Scrum because when done in the true spirit of Scrum, they enable a team to look at the highest value problems, imagine a compelling future, and use all of the thinking, collaboration, and creativity possible to put together solutions and plans. Then, you leave the people alone within the container of the sprint to apply their professional skills, without interruption so they can concentrate and focus on their work. This is the core of them being creative people doing creative work rather than resources being managed to optimize productivity.

Tweet This Post

Warning: The following post might provoke a mild aneurism to some scrum purists.

Don’t you love a nice, clean and deep Product Backlog, filled only with strong user stories tightly linked to clear business objectives and estimated by business value and story points?  As an Agile coach working with large organization with even larger challenges, I don’t usually have that luxury. And If I do, I don’t believe it!  The amount of stuff that needs to be done to ship out quality software is astronomical and never ceases to amaze me. So of course the “Definition of DONE” is equally immense.

The definition of DONE

Creating and shipping software in large organizations involves tasks and deliverables that go beyond straightforward testing, coding and releasing.  To get all this work out into the open, I ask teams to focus on a couple of “juicy” user stories and ask them to identify ALL that needs to be completed to get this product in front of the user.  We might get something like this:

And the list goes on and on…

Teams are then challenged to get everything done within a user story.   Of course this is impossible.  The best the team (and the supporting organization) can do for now is to complete some DONE items at the sprint, milestone, release or project level (see fig.1)

Figure 1

The further away we are from the user story level, the more nervous I get. At the beginning of an Agile transition, I can live with that as long as we identify these “non-story DONEs” as debt and we manage it appropriately.  I don’t judge or question any of the DONE items (ok, maybe I do, but not out loud) But I do want to the team and the organization to clearly see the sheer volume of overhead and offer them some kind of tool to start cutting out the fat.

This tool will be…The Product Backlog.

The team will manage this debt by adding non-functional work items in the Product Backlog.  In other words, all DONE items not included within a user story will become a work item in the Backlog. If the team’s initial estimate is 4 sprints for a release, then those sprint-level DONE items will appear four times. This continues with milestone, release and project DONE items. This makes for one polluted Backlog – And that’s ok…For now!  As you can imagine, this can double the scope of the project.

A product backlog can go from this:

To this:

What does it mean?

Based on the team’s velocity, it’ll probably take 4 to 5 sprints complete the project and not 2 – That is, if nothing changes. It means that it won’t take 15 points to produce $26,000 in business value but at least 33. Nasty!

It can also show an organization that went through a chaotic period and decided to structure all that is I.T. into a defined process; a normal reaction. Over design and over documentation is heavy and expensive, but it’s still better than the anarchy of the early years.

Finally, it means we need find the correct balance for this project and organization.

What do we do?

If the organization is polluted, so shall be the Product Backlog – Deal with it! No really, you need to deal with it.

The Product Backlog can’t remain in that state. It’s needs to be filled, almost exclusively, with items that deliver business value.  That said, don’t hide the real work that currently needs to be done or simply take that work into consideration by inflating story points.  It needs to be out there, for all to see.  We want to provoke a sense of urgency and change.

All the $0 business value items are now action items, things that a Scrum team and the surrounding organization need to deal with now.  If we can’t eliminate an item all together (Ex.: Code document? – I mean come on!), then we need to find out how we can reduce the effort needed to get it done.  We need to reduce waste and those dollars signs might motivate those upper management folks to get things moving.

This approach is provocative but in many large organizations, shock and awe is often required to encourage change.  If a Product Owner and ScrumMaster can clearly show that it costs $1 to create $0.25 of value, I promise you that something will happen.

So between a polluted Product Backlog and a clean one that doesn’t show us the full picture, I choose the former…For now!

Il y a un auditoire pour le premier sprint review, le patron du PO et un utilisateur expert sont présents. C’est encourageant!

Au début du sprint, l’équipe s’était engagée à livrer 3 stories, il y a 3 stories a démontrer. Bon départ! Un membre de l’équipe se prépare à démontrer le contenu de la première story. Je me permet d’intervenir et suggère que le PO prenne plutôt le clavier pour expérimenter lui-même le système et qu’il tente d’accomplir ses vérifications des stories (les conditions d’acceptation). Il vérifie la première story. Ca va bien! Les intervenants présents posent des questions. Il y a interaction entre les personnes présentes et ca sent l’intérêt envers la story livrée. Le PO navigue dans le système et confirme que le comportement est bon. Story acceptée. On passe à la deuxième story. Il y a autant de discussions dans la salle. On se rend compte qu’une règle n’est pas complètement respectée. Le PO hésite un peu, mais refuse la story. L’équipe est mécontente. « Ce n’est qu’un petit bug, on en a pour 30 secondes à le corriger, on pourrait quand même avoir 1.8 points (sur les 2 points que valait la story) ». Je fais mon méchant et je dis non; la story est refusée alors l’équipe n’obtient pas les points associés à cette story. L’équipe n’est pas contente! Je vais expliquer le principe plus tard, maintenant on termine le sprint review. Pour la dernière story, ca se déroule bien, les discussions continuent et le PO accepte la troisième story. L’équipe a réussi à livrer 4 des 6 points engagés. Ils gardent un mauvais goût de s’être vu refusé une story pour si peu. De mon côté je me dis que c’est l’apprentissage qui débute!

Coincé entre sa direction qui ne comprend pas encore les enjeux et les répercussions de la mise en place d’une approche de gestion de projet agile  et son équipe qui maintenant prend ses responsabilités, le manager d’une équipe agile reçoit des balles de toute part.

Bien entendu, tout le monde ne souhaite qu’une chose, réussir le projet. Cependant, les 3 protagonistes n’ont pas le même point de vue sur ce projet. Ils n’ont pas les mêmes connaissances de l’ampleur, du détail et de la difficulté de l’ouvrage. Ils n’ont pas non plus les mêmes besoins aux mêmes moments pour se rassurer (ou être rassurer) sur les chances de réussite ou sur la santé du projet.

Le gestionnaire agile dans les lignes de tir (photo by http://www.flickr.com/photos/mashleymorgan)

Lorsque qu’après avoir convenu qu’une première livraison de 2 mois permettrait de lever les risques et d’obtenir une ‘tranche’ verticale de logiciel fonctionnel, afin estimer de façon plus sereine le reste du projet, la direction décide de demander à l’équipe de réestimer la totalité du backlog après seulement 1 mois de travail, la fusillade éclate et le gestionnaire ou manager agile se retrouve dans les lignes de tir.

Satisfaire la demande de la direction ou soutenir l’équipe qui est tout à fait d’accord de réestimer le backlog, mais seulement après la release, une fois qu’elle aura l’information pertinente qu’elle cherche à obtenir.

C’est à ce moment là que le manager « au service de l’équipe » devrait faire son apparition. Être au soutient de l’équipe et l’éducateur de la direction.

Il doit être en mesure de répondre clairement aux interrogations des uns et des autres et d’expliquer à chacun les besoins de l’autre comme par exemple :

• Pourquoi la direction veut-elle une réestimation maintenant? Y a-t-il un besoin concret qui échappe à l’équipe comme par exemple une communication stratégique ou bien est-ce simplement une crainte, une insécurité générée par les nouvelles façons de faire, le nouveau reporting?
• Peut-on patienter encore quelques semaines? Admettons que les estimés préliminaires sont faux. Normal, ce sont des estimés! Ceux d’aujourd’hui, réalisés avec des connaissances encore incomplètes sur des risques identifiés, ne seront-ils  pas aussi faux? Seront-ils plus pertinent s’ils sont établits dans 4 semaines une fois les risques levés?
• Pourquoi l’équipe ne souhaite-t-elle pas réestimer maintenant? A-t-elle peur? Refuse-t-elle de communiquer, d’être transparent vis-à-vis de la direction? Pense-t-elle que l’investissement à ce moment donné n’est pas rentable? Manque-t-il des informations nécessaires?

Les arguments de tous seront valables. Alors que doit faire le manager? Rester au milieu et prendre les balles? Ne satisfaire personne? Ou bien se positionner et prendre le risque de décevoir sa direction ou son équipe?

Pour ma part, je pense que le calcul à faire est celui du succès de l’équipe. Est-ce qu’une journée d’estimation rapporte plus qu’une journée à coder pendant laquelle on apprend sur les risques techniques que l’on doit affronter? À certains moments peut-être, à d’autres non. Ce qui est certain c’est qu’une équipe frustrée qui ne se sent pas soutenue, est moins productive et performante.

Faire le calcul de répondre à la demande de la direction sans tenir compte de l’équipe est peut-être bon pour la carrière, mais n’est pas le meilleur moyen d’aboutir à une équipe auto-organisée, performante, motivée et responsable. Il est plus pertinent d’éduquer la direction, de la rassurer, de lui expliquer que l’équipe ne juge pas pertinent de réévaluer maintenant mais qu’elle le fera dès que possible et qu’il faut lui faire confiance. Il est aussi judicieux d’expliquer qu’en Scrum cette (ré)estimation est permanente et fait partie du cadre.

—

Vous serez peut-être intéressés par ce précédent billet :

• Faut-il réestimer les stories non terminées ou celles refusées par le PO à la fin du sprint?. N’hésitez pas à voter, votre avis m’intéresse

This is the plan for the next trip !

In the first sprint, we will make sure that the Turtle can sprint with the new Team Foundation Server Scrum v1.0 template announced at TechEd on Monday. You can download the new template here. We are really excited that Microsoft has decided to jump in the scrum world!

In the second sprint, we will implement a natural way to filter areas and iterations using a tag concept. You will have the option to put a push pin on some areas and iterations to apply a filter based on those selected and work with a subset of the work items. This will simplify backlog visualization and make sure the team’s focus is on delivering awesome software sprint after sprint.

This will help you doing enterprise scrum and complex project management with the Turtle.

If you want to manage your projects like one big project as suggested by Martin Hinshelwood on his blog, this feature will let you do that with Urban Turtle. I think you will really like this new feature.

Send us your comments on the forums!

Dominic !

Tweet This Post

What if sometimes, the best action to increase productivity would be shrink a team? I can think of two situations where reduced staffing is a good option:

• The team realized that it grew too fast. Core team members do not have enough time to effectively coach the rookies.
• A new features requires an overral architecture change. You can already predict that merging will be hell if new features are added while others are implementing the new architecture.

It’s not always feasible to remove team members – and it’s always a though decision. If the team grew too fast, you might not have any other choice. If you want to do it because you need a big architecture change, it might be possible to shift some members to another module or to start something new that will have no impact on a problematic area. You might also try to make the change coincide with half the team going in vacation (I’m sure many of you felt more productive when most of your team was away).

Next time you’re stuck and have a hard time finding effective ways to make the whole team work together, consider a reduced staff for a few weeks. It might be just what you need.