Leveraging the Team for Good PDPs (if you need them)

I am currently working with a relatively new Scrum team (5 Sprints/weeks young) that needs to rewrite their Personal Development Plans (PDPs) in order to better support Scrum and the team.  PDPs are still the deliverables of individuals required by the organization and likely will be for some time.  The organization is still in the early days of Agile adoption (pilots) and they are large.  So, instead of giving them a sermon on why metrics for managed individuals are bad, I am going to help them take the step towards Agility that they are ready to take.

The Plan:

  • Facilitate a team workshop to create an initial Skills Matrix;
  • work as a team to develop a PDP for each individual team member that directly supports the team’s high-performance Goal (already established)—
    • in other words, when considering an appropriate PDP per individual, the team will start with the team’s performance Goal and build the individual PDP from there;
  • develop a plan as a team for how the team will support each team member to fulfill his/her individual PDP—
    • in other words, all individual PDPs will be part of the team’s plan for team improvement;
  • Internally publish the plan (share with management).

I’ll follow up with another post to let everyone know how it goes.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Real Agility Program – Execution and Delivery Teams

Execution IconIn a recent post, Mishkin outlined the Leadership Team component of the Real Agility Program.  While the Leadership Team track focuses on developing leadership capacity for sustained transformation, The Execution track focuses on launching and developing high-performance project, product and operational teams.  This track is the one that most of our clients use when they run Agile pilot programs and is a critical component of getting quick wins for the organization.

Groundbreaking works such as The Wisdom of Teams (Katzenbach & Smith), The Five Dysfunctions of a Team (Lencioni) and Drive (Pink) have served well to distill the essential requirements of high-performance teams.  Scrum, Kanban, and OpenAgile are proven frameworks that optimize the value of teams and create the necessary working agreements to help teams reach that high-performance state.

The Delivery Team track of the Real Agility Program creates new, cross-functional, multi-skilled, staff-level teams of willing individuals.  These teams are responsible for delivering value—business results and quality.  Individuals are committed to the performance of the team and the organization.  Teams develop the capacity to self-organize and focus on continuous improvement and learning.  A team is usually composed of people from various roles at the delivery level.  For example, and IT project team might be composed of people whose previous* roles were:

  1. Project manager
  2. Business analyst
  3. Software developer
  4. Tester
  5. Database developer
  6. Team lead
  7. User experience lead
  8. Intern

* These roles do not get carried into the new delivery team other than as a set of skills.

The track begins with establishing pre-conditions for success including executive sponsorship, availability of team members and management support.  Team launch involves a series of on-the-job team development workshops designed to enable the teams to create their own set of values, working agreements and high-performance goals.  Teams are guided in the creation of their initial work backlogs, defining “done”, estimation and planning and self-awareness through the use of a collaborative skills matrix.  The teams are also assisted in setting up collocated team rooms and other tools to optimize communication and productivity.

Qualified coaches assist the teams to overcome common issues such as personal commitment, initial discomfort with physical colocation, communication challenges of working with new people in a new way, management interference and disruptions and appropriate allocation of authority.  This assistance is delivered on a regular schedule as the team progresses through a series of steps in the Execution track process.  Usually, these steps take one or two weeks each, but sometimes they take longer.  A team that needs to get to a high-performance state quickly might go through the entire program in 10 or 12 weeks.  In an organization where there is not the same urgency, it can take up to a year to get through the steps of the track.

The coaches for this Execution track also help management to resist and overcome the strong urge to manage the problems of the teams for them.  In order to develop through the stages of team development, teams need to be effectively guided and encouraged to solve their own problems and chart their own courses towards high-performance.

The goal of the Execution track of the Real Agility Program is to help the team go through the stages of forming-storming-norming and set them up to succeed in becoming a high-performance team.  Of course, to do this requires some investment of time.  Although the Execution track is meant to be done as on-the-job coaching, there is a 5% to 20% level of overhead related to the Real Agility Program materials themselves.

See also the article on the Recommendations component of the Real Agility Program.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Updated: Reviews of SAFe (Scaled Agile Framework)

I just finished attending my SAFe Program Consultant (SPC) training and I wrote a review of the Scaled Agile Framework 3.0 and the SAFe Program Consultant training.  I won’t quote myself here :-)

Lyssa Adkins

Also, Lyssa Adkins has recently published her own review on InfoQ.  I enjoyed reading it because Lyssa is so gentle, fair, and insightful.  She puts a lot into connecting the Scaled Agile Framework with the Agile Manifesto and shows that there is a fantastic level of alignment between them.  Her article is called “Agile Coaches’ Coach Shares Her View on SAFe“.  Here’s a bit of a teaser from her article:

Based on the way the SAFe Big Picture looked to me, I walked into that class very concerned that SAFe would take away the teams’ creativity by “pre-chewing” the stories into requirements a la my project management days. I thought I might see the rebirth of “The system shall…” statements. I was also worried that SAFe would take away teams’ autonomy and reverse our still fragile belief in emergence; the diagram just looks so top down! These concerns put me on alert for anything that appeared to undermine the Agile Manifesto or the Scrum values.

 

A surprising thing happened in that class…..

Peter Saddington

Although I don’t know him well, the few small interactions I’ve had with Peter have engendered in me a great deal of respect for him.  His fundamental philosophy of Agile and organizations is courageous and principled.  I found out yesterday that Peter wrote a review on the Scaled Agile Framework back in February 2014.  Please check out “The Scaled Agile Framework (SAFe) – A Review“.  It is interesting and insightful.  Great quote:

What SAFe is Far Better At Than Most

- Marketing

Ron Jeffries

SAFe (Scaling Agile Framework) is gaining in popularity.  Ron Jeffries recently attended a SAFe training session and has written a great review.  I particularly like what Ron says about the idea of being properly Agile:

SAFe will be successful in the market. People will benefit. They just won’t benefit nearly as much as they might if they set out to do things in a fashion that truly supports Agile Values and Principles.

 

SAFe is good. It’s just not good enough. It provides some benefit, but endangers an organization’s progress toward really high functioning. As someone who has been in the Agile movement since before it started, I do not like it. It’s fast food. You can do better.

 

Mike Cohn

Mr. Cohn has written a really fun April fool’s parody of SAFe that, given the comments, surely counts as a review as well.  It’s called “Introducing the LAFABLE Process for Scaling Agile“.  Although it starts on a very humorous note, the comments are quite extensive and contain lots of great discussion.  Here’s an important comment from Mike Cohn about the whole concept of scaling that gives you a taste of the discussion:

I don’t think “agile at scale” is a bad word. I’ve consistently maintained that projects should be as agile as they can be but no more. A project that requires let’s say 500 people will never be as agile as one that requires 3 people. But I can’t imagine the 500 people and 3 people being competitors. And, if they are, the bigger mistake made by the 500 person project is involving the other 497 people, not the process they choose.

Neil Killick

Neil Killick seems to have even stronger opinions about SAFe, and is quite direct about them.  I like what he says in one of the comments on his blog post:

So you can go the SAFe path or the Scrum and Agile path. All you need to do i[s] figure out how big a cliff you want to deal with down the road.

I don’t personally have any experience with SAFe so I won’t make any big claims about it either way.  However, I do appreciate that the popularity of SAFe, like the popularity of Agile/Scrum* will probably lead to studies showing modest qualitative improvements of 20% to 40% increases in productivity.  Is this just the Hawthorn Effect at work?

When I help an organization with Agile principles and methods, I hope and expect dramatic measurable improvements.  Sometimes this results in people losing their jobs.  Sometimes this means people have nervous breakdowns.  It can be very painful in the short term.  SAFe, by it’s very name, seems to be anti-pain.  That doesn’t bode well.

Here are a few other interesting links to information about the Scaled Agile Framework:

Has SAFe Cracked the Large Agile Adoption Nut? – InfoQ

Unsafe at Any Speed – Ken Schwaber

Kanban – the anti-SAFe for almost a decade already – David Andersen

* There is no such thing as “Agile/Scrum” but that’s what lots of people call Scrum when they don’t do Scrum properly.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: I do not track my hours or my “actual” time on tasks

Scrum considers tracking the time individuals spend on individual tasks to be wasteful effort.  Scrum is only concerned about time when it comes to the time boxes of the Sprint and Sprint meetings.  Scrum also supports sustainable development, which implies working sustainable hours.  When it comes to the completion of tasks, the team is committed to delivering value.  The tasks in the Sprint Backlog represent the remaining tasks that the team has identified for delivering on its committed increment of potentially shippable value for the current Sprint.  The tasks themselves have no value and therefore should not be tracked.  Scrum is only concerned about burning down to value delivered.  Time spent on individual tasks is irrelevant.  What if I track my hours or my “actual” time on tasks?  This promotes a culture of “bums in seats” – that it is more important for people to be busy at any cost instead of getting valuable, high-quality results.  This also promotes bad habits such as forcing work into billable hours even though it is not.  Overall, time tracking in a Scrum environment does much harm and can undermine the entire framework.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: No member of my team reports to me

Inside the Scrum Team, including the Product Owner and the ScrumMaster, no individual should report to any other individual.  The team reporting structure should be flat.  This does not necessarily mean that all Team Members are peers in the org chart.  For example, one team member could be quite senior, and another quite junior.  However, for the Scrum principle of self-organization to work effectively, individual Team Members should have no concern about what their “boss” wants them to do.  Instead, within the Scrum Team, there should be a completely safe environment for individuals to volunteer for tasks, raise obstacles, provide candid feedback to any other Team Member, and have a mutual sense of commitment to the work of the team.  If the Scrum Team is absent of reporting relationships then it has a much higher chance of becoming a high-performance team.  If there are reporting relationships within the Scrum Team there are often significant obstacles to full openness and self-organization and this, in turn, will significantly hamper the performance of the team.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: I am willing to learn any skill needed to help my team

Scrum Team Members, excluding the ScrumMaster and Product Owner, must be completely open-minded to learning new skills.  Skills can be technical, business, personal, tools-based, etc.  A Team Member is sensitive to the needs of the Scrum Team and will learn skills by multiple means as the needs of the team evolve.  A Scrum Team where people are not willing to learn new skills will suffer from bottlenecks, time pressure, quality problems, and often will become generally demoralized as the willingness of some people on the team turns into apathy and cynicism when others refuse to learn.  In a team where everyone is willing to learn new skills, there will be a consistent raising of capacity and the team will be able to do more and more work more effectively.  This attitude is a key requirement for the formation of high performance teams.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: I actively seek to help my team mates

A Scrum Team Member is aware of the work that other Team Members are doing, notices if others are struggling with their tasks, and if so, offers to help them.  A Scrum Team Member is not just focused on their own personal tasks.  This help can be offered as ideas, powerful questions, sharing the work of the task, or even offering simple encouragement.  If Team Members are constantly seeking to help each other, this actively contributes to team cohesion, cross-training, and the development of a high-performance team environment.  Of course, if people don’t help each other, then individual Team Members may struggle for a long time without making progress and overall productivity will be dramatically hindered.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

What is Scrum good for?

I have worked with a lot of people, teams and organizations over the last 8 years helping them to adopt Scrum and I have seen some interesting patterns about where Scrum works well and where it doesn’t work so well. I wanted to share my observations to see if they correlate with what other people are experiencing.

So first off, I want to describe what I mean by Scrum working well:

  1. Teams using Scrum are obviously high-performance teams whose business results are at least 4x that of normal teams.
  2. The organization in which Scrum is being used experiences a change in culture to become more team oriented, more value oriented, and more customer oriented.

So now I can describe where I have observed Scrum to work really well:

  1. When an organization (or team) is in deep trouble and willing to admit it adopting Scrum seems to be a catalyst for creating a new culture, process and team environment where getting out of trouble is possible. This is Scrum for Crisis. The “willing to admit it” part is extremely important as I have worked with two organizations where the “deep trouble” part was obvious to me as an external person, but in both cases management and staff did not seem willing to admit the depth of their crisis and in both cases Scrum failed to act as a catalyst to get them out of trouble. In this use of Scrum, sometimes resolving the crisis then leads back to complacency and Scrum fades away.
  2. Small growing organizations that have no existing formal processes for development can use Scrum as an effective way to maintain their high-performance without getting burdened in bureaucracy. In this case, it is important to note that they are _already_ in a high performance state and their struggle is to maintain that while at the same time growing. I’ve worked with quite a number of small organizations where all they need is the CSM (plus maybe one or two days of coaching) to adopt and maintain Scrum. I have also worked with small organizations that were _not_ already high performance and Scrum has not typically worked to bump them up to a high-performance state.
  3. Pure new product development where a single strong Product Owner can be identified who has the authority to make product decisions independently of anyone else (including product budget decisions). By “pure new product development” I mean that neither the individual team members nor the team as a whole have any responsibilities outside of the product work – there is no “fractional allocation” or “resource levelling” across projects or products. The strong Product Owner is critical to success with Scrum and must understand the principles of Scrum as well as the mechanics of being a Product Owner.

I have also seen Scrum be inappropriate and not lead to the results I mentioned above:

  1. Management teams. It seems like Scrum could or should work for management teams, but it appears that managers have too much of the following problems to be able to use Scrum:
    - operational responsibilities (non-creative, non-problem-solving work)
    - urgent, legitimate interruptions (e.g. an escalated customer issue)
    - real commitments to events or projects that are calendar based (e.g. a management off-site)
    - ego: they don’t want to follow an apparently rigid process or they are always happy to make exceptions for themselves
    Again, one might imagine that Scrum _should_ work to help resolve these issues, but unfortunately I have never seen it able to do so in this context.
  2. Small teams/projects. Scrum is too heavy for teams less than 5 people or for projects shorter than 2 months in total duration. Those numbers aren’t meant to be hard and fast, but when I’ve seen small teams/projects attempt to do Scrum they _always_ end up breaking lots of the rules partly because they can and partly because they must. That said, some folks have created “Personal Scrum” and other variants. I’m not sure if we as the Scrum Alliance officially recognize/endorse those variants.
  3. Purely operational work. There just isn’t enough creativity/problem-solving to make the Sprint an appropriate process element, nor the Product Backlog an appropriate organizing mechanism. I have seen some operational environments get some benefit from doing regular retrospectives, but just doing retrospectives is not Scrum in my book. My experience with Kanban is still a little limited, but it seems to be an appropriate approach for these environments.
  4. Organizations where there is very little need to change. I’ve spent some time working with big profitable banks to adopt agile and without exception, they just can’t wrap their minds around the need for Scrum… because they are already so successful as a business. The general attitude is that Scrum is popular therefore we will call what we are doing “Scrum”, but it really isn’t. It’s Scrummerfall and Scrum-Butt wrapped up in the terminology of Scrum. They will adopt some Agile practices and get very modest benefits. I have seen minor improvements in team morale and minor improvements in quality and productivity, but certainly not anything near to what is possible for improvements. When we do assessments in this type of environment, we see Value Stream maps with waste at the 80-90% level so there is huge room for improvement… but it just doesn’t happen.

Scrum can definitely transform the world of product development. It can definitely act as a catalyst to get teams and organizations out of crisis. But that isn’t the whole world of work. I’m also concerned about the idea of using Scrum for general project management. There might be some good practices that are part of Scrum that would also be valuable in general project management (e.g. regular retrospectives, daily team meetings) but that doesn’t make Scrum a general project management framework.

I don’t claim that any of the above observations are “correct”. That’s partly why I am sharing – I would love to have a good discussion here about this because I think it is critical for us as Agilists to be able to answer this question well when we are asked: “what is Scrum good for?” – particularly since Scrum is by far the most popular Agile method.

I would love to hear other people’s observations about where Scrum works well (as I have defined “well” above) vs. where it either is only a modest improvement to existing approaches or where it might even not work at all.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail