From Kane Mar, here is a good summary of thoughts and approaches to doing Agile performance reviews.
Recently, I was able to witness a remarkable event in a company that is relatively new to Agile. They have several teams at about Sprint 12, with several new teams just starting up. Many of their processes are waterfall based.
A failed waterfall project was moved to an existing Agile Team.
In the second Sprint, the Team (feeling trust in the organization and the process), came to the Scrum Master and said, “We’d like you to talk to management. We are not sure this project should be using the platform we develop on. We think another team’s platform may be more appropriate”.
The company had spent time developing a “specification document” for this “project” before Agile was introduced. There were detailed specifications as to how the product was to be created and which platform to use. NONE of this was done with the benefit of asking those that would actually be doing the work.
The project was initiated before learning about applying Agile. One developer was tasked with following the specification. After 2-3 months of frustration, the developer left. This left the company in a bad position. Not only was the project incomplete, but there was also no knowledge transfer. The project was basically stopped.
As Agile was now the new target way of doing things, the project (and new developer hired through the previous process) were added to an existing SCRUM team. The team is using one week Sprints.
After only two Sprints (two weeks), the team had recognized the futility of the approach that was “specified” and took this to management.
Traditionally, large organizations staff for projects. In an environment such as this, how could team members be expected to be truthful and honest about the state of affairs? It would mean the end of their jobs or contracts.
The key here is to allow teams to stick together. Not only will you avoid losing all the efficiency the team has built up, but you will also allow them to be truthful about their situation.
If you are a manager reading this, ask yourself. “Do I want to know that things will go wrong at the beginning of the project or wait until 5 months have gone by to be told, ‘We knew it would never work”". Or even worse… “We knew the product owner was asking for ridiculous features that had no Return on Investment for the company, but hey, you hired us for this contract. We just follow instructions”.
As it turned out, the project did continue with the current team, but with some changes to the specification. The parts of the system that were going to be problems in 5 months were re-evaluated and were removed as they really did not have any real value to the company. It was then decided to stick with the same platform.
Discussions did occur regarding moving to the alternate platform, but were deemed unnecessary after open discussion between the teams and the managers involved. Realistic expectations were set based on value to the company.
Sometimes features are absolutely mandatory for the product. This cannot and should not be taken away from the process. What we gain here is that we are able to have a discussion about necessity. In the end, the business has to decide what is valuable, not the development team.
In a case like this, ask yourself, “If my team is very against this, maybe I should at least think about it”.
The company is working in a very short iterative environment, they quickly recognized a flaw in the system design and dealt with it after only 2 weeks into a several month project.
Working incrementally allows the company to “Inspect and Adapt” on a regular basis. This has to include the question, “Does this still make sense?”. If you need to go backwards, let it be to reverse one or two Sprints of work, not months, or even years.
Fortunately, for the company, the product will come out on time, with appropriate technology based on Return on Investment, and likely with significant cost savings over the initial design. This will also allow the team to get started on other high value projects. Talk about win-win.
This project could have gone to another team. It would not have been negative for the first team. The next project would have just come down the pipe for them.
The early signs helped adjust the “expectations” and everyone is moving forward with a clear understanding that they are on a more appropriate path going forward.
For those of you out there trying to convince companies (or yourselves) that Agile is an effective framework, don’t be afraid to talk about “RISK MITIGATION“.
Think about it this way; The company wants to know early on that there will be a problem, not near the end of the project. This is part of the purposeful transparency of any Agile framework.
Mike Caspar’s Blog
A manager I am working with recently sent me this link. I have seen this topic discussed before, but never so nicely worded. Thanks Charles.
It is a discussion about how Jazz music is different than Classical music and how that knowledge could help to understand Agility.
Great post. I think we’ll hang this on the wall somewhere in the team room.
“I now can see why Corporations have such a hard time identifying the Scrum Master in their organizations. Scrum Masters basically don’t fit either category, yet most corporate hiring is done based on hiring of “leaders” and “managers”.”
For the complete text click here
Michael Badali, a good friend of mine, has asked a great question on LinkedIn: What is your Backlog for Agile Transformation?. From his question:
While I think that Band-Aid off quick is more likely to be successful than Band-Aid off slow, often Agile Coaches & Leaders are put in the position of Kaizen instead of Kaikaku. When asked for a detailed waterfall plan and schedule on how to become Agile… I generally refuse and create an Agile Transformation Backlog – a prioritized list of things that need to be done to become Agile. Please share your prioritized list of things that need to be done to be Agile.
Just heard about this through my network (thanks to David Chilcott): http://www.meebo.com/jobs/openings/scrummaster/
Hello loyal readers… over the last month we have become aware that this site has been hacked so that it sometimes displays content that is unrelated to the site itself. We have fixed it a number of times, and we hope that we will be able to keep it fixed. However, if you should come across content that is clearly inappropriate for this site, please let me know. I would appreciate a screen shot or other specific information about the inappropriate content so that I can take specific action. Please email me at mishkin at berteig consulting dot com. Thanks!
Scrum is the most popular agile method… if you count all of the teams doing “Scrum Butt”. Doing Scrum really well is much harder and much rarer. Here is a list of 24 common pitfalls or bad behaviours of Scrum teams:
- Excessive Preparation/Planning: Regular big up-front planning is not necessary with Scrum. Instead, a team can just get started and use constant feedback in the Sprint Review to adjust it’s plans. Even the Product Backlog can be created after the first Sprint has started.
- Focus On Tools: Many organizations try to find an electronic tool to help them manage the Scrum Process… before they even know how to do Scrum well! Use manual and paper-based tracking for early Scrum use since it is easiest to get started. Finding a tool is usually just an obstacle to getting started. (And besides, check out what the Agile Manifesto says about tools.)
- Problem-Solving in the Daily Scrum: The Daily Scrum should not be used to find solutions to problems (obstacles, impediments) raised. Instead, keep the meeting very short and have those problem-solving conversations afterwards with only those who are interested. The ScrumMaster facilitates this meeting to keep it on track.
- Assigning Tasks: Even though the concept of self-organizing teams has been around for a long time, still some people think that a project manager or team lead should assign tasks to team members. It is better to wait for someone to step up than to “take over” and assign a task.
- Failed Sprint Restart: Although cancelling a Sprint is rare, it can be tempting to try and wait until everything is “perfect” or “ready” before re-starting. Teams should immediately re-start after cancelling a Sprint.
- ScrumMaster As Contributor: The ScrumMaster is like a fire-fighter: it’s okay for them to be idle – just watching the team – waiting for an emergency obstacle. Taking on tasks tends to distract the ScrumMaster from the job of helping the team follow the rules of Scrum, from the job of vigorously removing obstacles, and from the job of protecting the team from interruptions.
- Product Owner Doesn’t Show: The Product Owner is a full member of the team and should be present at all Scrum meetings (Planning, Review and Daily Scrums). As well, the Product Owner should also be available during work time. Of course, the PO also needs to work with stakeholders and might be away during that time, but these discussions should be scheduled outside of the team’s meeting times.
- Stretch Goals: The team decides on how much work it will do in a Sprint. No one should bring pressure on the team to over-commit. This simply builds resentment, distrust and encourages low-quality work. That said, of course teams can be inspired by challenging overall project or product goals.
- Individual Heroics: Individuals on a Scrum team should not do excessive individual overtime, or in any other way try to be the “hero” of the team. Scrum helps us build great teams of people, not teams of great people (quote from Barry Turner).
- Team Organizes Product Backlog: The team does not have proper insight into the needs of users and instead should be focused on solving technical problems. The Product Owner needs to be accountable for ROI and therefore should resist any pressure from the team to do things in a particular order for “technical” reasons.
- Product Owner Specifies Solutions: The Product Owner must allow the team full freedom to come up with solutions to the problems presented in the Product Backlog. PBIs should be free of technical specifications unless they can be tied directly to a customer or end-user request.
- Urgent Interruptions: Urgent interruptions should not be allowed in a Sprint… instead, if it is urgent enough, the team should cancel the Sprint. Otherwise, the interruption should be put on the Product Backlog and deferred until the start of the next Sprint.
- Making Assumptions: Often team members will fail to ask the Product Owner about details of the work they are doing. A team member solves problems, but it is critical to know about constraints. The feedback between PO and Team Member should be ongoing throughout every day of the Sprint.
- Not Getting Done: This is hard to prevent from happening from time to time, but it can become a habit for a team to over-commit. Make sure that a team that is doing this is using burndown charts effectively and is holding demos even when they have not completed all their work.
- Demo Not Ready: Sometimes a team forgets that it will take time to prepare for a demo: cleaning the team space, setting up a demonstration environment, getting scripts ready, and ensuring that critical stakeholders are prepped. These activities can be part of the tasks in the Sprint Backlog.
- Prototype Not Shippable: A Scrum team should attempt to produce production-quality, “potentially shippable” software right from the very first Sprint. Building prototype code just delays the inevitable need to write production code. Similarly, wireframes, detailed designs and other similar tools should also be avoided.
- Distributed Team: Although Scrum does not officially require team members to be collocated in a “war room”, the reality is that any distribution of team members (even just into separate cubicles) has a huge negative impact on transparency and communication, which in turn has a huge impact on productivity and quality.
- Directive ScrumMaster: The ScrumMaster needs to be a facilitator who supports the team in learning self-organization, and the Scrum rules. The ScrumMaster should never succumb to the temptation to suggest how a team member does his or her work, nor what task next to work on.
- Changing Team Membership: Scrum is a framework for creating high-performance product development teams. If the membership of a Scrum team changes, it forces that team to re-start the Forming-Storming-Norming-Performing sequence. If the team is in Norming or Performing, then changing team membership for any reason is a waste of quite an investment.
- Non-Scrum Roles on the Scrum Team: It is very common for an organization to create a Scrum team without changing the official title and duties of the people who are members of that team. For example, a person who is a Project Manager might be given the responsibilities of the Product Owner without an official change of title. Scrum teams should only have a ScrumMaster, a Product Owner, and Team Members.
- Giving Up On Quality: Scrum has very high demands on teams regarding the quality of their results: “potentially shippable software”. It is easy for a team or organization to fall back on the crutch of defect tracking software instead of maintaining extremely high levels of quality at all times (due to pressure to release features).
- Imposed Deadline Scope And Resources: Scrum is reality-based. If an external stakeholder wants to impose a minimum scope, a deadline and constrain the resources available to the team then they must allow that quality will slip… which in turn is against the principles of Scrum. The reality is that no-one can predict the future so any such imposition is simply a fantasy.
- Definition of “Done” Imposed: There is confusion between the concept of the definition of “done” and “standards”. Managers and other stakeholders often incorrectly impose standards on a team as its definition of “done”.
- ScrumMaster Not Present: I once saw an organization that had created a room for a “team” of ScrumMasters. They worked there together most of the time! The only time the ScrumMaster should be away from the team is when he/she is working on removing an impediment that is outside the team. Otherwise, the ScrumMaster should be in the team’s room.