Tag: Agile

What Happens if We Fail One or Two Sprints?

(First published on the Scrum Alliance Website)

 

I ran a Scrum Master Summit for my company recently where we invited the 42 Scrum Masters for a day of learning for them and for us. At the end of the planned session we had a “Lean Coffee” discussion where anyone could vote on the topics for discussion.

 

One of the more interesting topics that unfortunately didn’t get any votes, was “What happens if we fail 1 or 2 sprints?”.

 

I think you should be failing more often than 1 or 2 sprints.  As a team we need to be challenging ourselves more, trying new things, and experimenting. That will lead to failure, which will lead to learning which is great for it’s own sake.  I want the teams to fail, but I want them to fail fast. Try something new for a sprint, see if it works, how you can tweak it, what is un-usable, what can be taken away and then start again. Get into a pattern of trying and failing.

 

In talking to the Scrum Master who wrote this, their concern was around velocity. They are concerned that they should be hitting the exact number each and every sprint. It’s actually good that they are NOT hitting the number sprint after sprint.  They should be challenging themselves with a higher number every once in a while. It would be too easy to not challenge yourselves and keep the same number sprint over sprint, set the number 10 points lower than what you know your team can do and coast.  But that’s not good for the morale of the team, for the education of the people, for the project/sprint, really for anyone.

 

So they should set the sprint goal higher than what they have been, with the team’s agreement.  And not just gaming the system by making a 5 point story an 8 point story, but by taking on more than what you would normally and seeing if you can do it.

 

Or keep the same velocity target and trying pair programming. Anything that gets your team trying new things, learning and pushing their boundaries, either personal or team based.

 

The question however has some deeper undertones unfortunately.  Traditionally in the work world failure is punished and we have ingrained the fear of retribution into our people. I think the question is based on that, the “What will management do to us if we fail 1 or 2 sprints?”.  I think most companies that are working in an agile manner and have adopted the agile mindset will be open to experimentation and failing. Fortunately where I work we are encouraging this, we want our people to try, to strive for more, to learn and yes to fail. Management will do nothing if you fail, so keep trying.

 

Velocity and other metrics are meant to offer a team an opportunity to improve, to give them insight on how they are performing.  They are not to be used to measure teams against each other, to say that team “A” is better than team “B” simply because their velocity is 10 points higher. Management should be looking to the teams to see how they can help them become better, not to be using metrics as a punishment tool.

 

To answer the original question “What happens if we fail 1 or 2 sprints?”; you learn.

Agile from the eyes of a 20 year PMP veteran – No Project Plans

I admit, I used to love project plans. I was a master of MS Project, with a sub-specialty in GANTT charts. I could link and unlink, change durations and critical paths with the best of them. You need a project to end in November, bang! it ends in November (the 30th, but still November).

Now, I cringe when I see them. I realize how much wasted time and effort went into these. And the wasted bullshit. “Can you finish testing by the 15th?” “Abso-fucking-lutely” and they still aren’t finished to this day.

Douglas Adams summed up deadlines very nicely with this:

Deadlines - adams

Hours spent changing dates, futzing with dependencies, all to make something that wasn’t going to happen. Countless useless meetings, that had been scheduled and re-scheduled multiple times, which to be honest, should have been the first clue that the plan wasn’t going to work.

Under Agile the fixed project plan goes away in favour of getting work done.  However,  the Project Management Pyramid still holds in one aspect, flexible scope.

Project Managment Pyramid

Utilizing Agile you are able to get a better understanding of scope and, it seems, people are more willing to negotiate on scope, which helps bring in the cost and time elements as well. You only have 3 months until release? Fine, we are going to work on the items that have the highest value.

All this doesn’t mean you don’t need to have a plan (and saying this is going to make some of my friends in the Agile community get mad at me).  There are other parts of the organization that rely on the output of the development effort and need to have an awareness of when things are happening so they can coordinate items on their side.  Letting Load & Performance testing know that you are delivering, and when you are delivering, gives them the ability to plan for the work that is coming to them. Release management, sales, marketing, security, hosting, and support are all groups that need to have a forward notification that projects are coming their way.  The main difference between a ‘traditional project plan’ and the agile plan is the way in which it is communicated.  You don’t need to send a thousand line plan to all the stakeholders to get their approval and buy in.

project plan updated

You need to involve them in the Vision Sessions, the demos, and grooming sessions so they know when things are coming their way, can better plan for what is coming and put items on their own boards to handle the workload and timing. I’ve held hour long ‘planning’ sessions (they really were scrum of scrums but I couldn’t title them that) to make sure all the teams were aware of what was coming, and what changes were happening in schedule and scope.

No need to spend hours updating and sending out a project plan before a meeting, only to have the content of the plan change during the meeting, requiring a subsequent update that becomes out of date as soon as it was documented. Communication is the key.

Fun Communication skills game

I been working with Jason Little (@jasonlittle) on delivering Vision Collaboration Workshops for my company, PointClickCare. By ‘working with’ I mean he’s been doing all the presenting and I get to stand around, watch him and chip in my 2 cents whenever necessary.  I will be conducting this workshop on my own in the coming months and leaning on Jason’s experience to get me through them.

One of the great games that he has introduced me to is a communications game that highlights the benefits of doing things the agile way.

You break the group into two teams, “Product” and “Developers”.  Have the Developers leave the room while you give the instructions to the Product team.  The Product team is given a picture:

Agile

 

and 5 minutes to write a specification document describing how to draw this.  The Developers come back in and read the spec and draw what they have read.  They are not allowed to ask the Product any questions other than handwriting clarifications.

You get some very interesting diagrams:

Agile drawing

Agile Drawing 2

Bull Symbol Agile Drawing

The instructions said “draw the bull symbol from the stock exchange”, so I can see how this happened.

Ask the Product people if they would accept this version and the vast majority reject.  There are some exceptions, this drawing, for example was fantastic:

2016-08-17 16.01.52

The next round has a different drawing and a different set of rules.  This time, in 5 minutes, you have the Product and Developers sit together and the Product describes what they want while watching the Developers draw.  The only rules are they can not show the Developers the picture and they can not use their hands.

After the 5 minutes you get a very different result. Nearly everyone experiences a sharp increase in acceptability, a better drawing that closely matches what they were working from.

I’ve used this as a team building exercise for a couple teams outside of agile and had great success with it. When using it for communication techniques, I had the teams sit back to back for the first round instead of writing out the requirements. The second round I had them facing each other. It really highlights the benefit of proper communication.

Difficulty: Easy

Agile from a 20 year PMP veteran – Where does the work of the PM go?

The PM’s time is spent on a myriad of activities (as found here):

• Planning and Defining Scope   • Activity Planning and Sequencing   • Resource Planning   • Developing Schedules   • Time Estimating   • Cost Estimating          • Developing a Budget   • Documentation   • Creating Charts and Schedules   • Risk Analysis   • Managing Risks and Issues   • Monitoring and Reporting Progress   • Team Leadership   • Strategic Influencing   • Business Partnering   • Working with Vendors   • Scalability, Interoperability and Portability Analysis   • Controlling Quality   • Benefits Realisation

Notice the centralization of responsibility and the single focus on this one individual for the planning (mentioned several times) and documentation as referenced by ‘estimating’, ‘developing’ and ‘analysis’.  The PM is the one person with their neck in a noose as far as the project goes, a very visible and real alliteration of what happens if the project doesn’t go well. But also notice that of all of these actions, none of them create any real business value.  They are all based on making sure everyone knows what they are doing and where the project is going.

The real business value is created by doing actual work.

Planning and defining scope happen in real time and is distributed between the entire team. Distributed work is still getting done, however with Agile it’s getting done as needed and it’s not a separate phase of a project.  Same goes for almost all of the other activities; they are all done as and when needed and not as a stand alone effort.  As well, the work is distributed to the entire team or it is deferred indefinitely.

Having some great success with this warm up exercise

I learned this one a few months ago and have been using it in retrospectives and in some of the training I have been part of.  It’s called “Fortunately/Unfortunately”. I explain that this warm up exercise helps with communication skills by making the participants actively listen to what the previous person said and then responding appropriately.

The instructions are quite simple. The first person in the group starts a sentence with “Fortunately” and the next person follow up on the sentence with “Unfortunately”.  It’s important that they listen to what was said and make their sentence follow the same theme.  During one session I had started with “Fortunately my wife is pregnant” and the next person, who obviously wasn’t paying attention stated “Unfortunately the Raptors are out of the playoffs.”.

I use the “Fortunately my wife is pregnant” when I am explaining the game to the group because it also loosens them up and gets them laughing as I follow that statement up with “Unfortunately the baby isn’t mine”!

During this exercise there is a lot of laughter and creativity, which really helps everyone loosen up before your session.

Difficulty: Easy

Agile from the eyes of a 20 year PMP veteran – Leading from Behind

One of the biggest challenges for Project Managers in making the transition to Agile has to be the way that they need to do their daily job.  The PM is typically the leader of the project, the one that sets the pace and direction, that makes all the key decisions to ensure that the project is finished “On time and on budget”. This changes when they work on an agile project as they are not in front of everyone directing what everyone is doing and creating report after report.

A project manager is responsible for the 5 stages of a project: Initiating, Planning, Executing, Monitoring & Controlling, Closing. They take responsibility for the project and nurture it and the team to get the required result.  The PM is used to, in fact instructed to be the guiding hand of the project, ensuring that the project is completed as per the PM’s wishes.  The PM has to lead in order to do their job.

Contrast this with the role of Scrum Master or even the Product Owner.  Each of these roles has a responsibility to make sure the project is going smoothly and that the team is operating at its optimal level.

The Scrum Master is not the leader of the project, but they do play a crucial role. The Scrum Master is more of a coach for the team, helping them produce the work, but they don’t manage the team.  The responsibility is more towards making sure that the Scrum process is followed, removes roadblocks and supports the product owner.

Not everyone can make the shift from PM to SM, and many just shouldn’t even try.  The mindset and skills to lead from behind is much different than the PM’s direct managing/ordering work done.  In order to make the transition a PM would have to let go of their ego and realize that the project does not revolve around them, but instead it revolves around the team.

It seems that a Project Manager is like a babysitter and they treat the team like a bunch of children; if they don’t do what the PM says they get in trouble, they have do bet watched at all times, you need to report to management (the parents) what the team is doing, the PM mediates disputes, and if something bad happens the PM is blamed.

The Scrum Master, however, is more like the coach of a professional sports team; everyone knows their role and is eager to do what they do best, the SM guides the team and keeps them aware of the rules, each member of the team helps other members collaboratively and the success of the team is shared equally.

Being a SM is more about enabling the team to do their best work possible and removing any barriers to success.

 

Another benefit of Agile

When I ran a team, there was the need for weekly or at least monthly, staff meetings.  Not to, as the comic suggests, get my ego stroked but to make sure everyone was up to date with what everyone else was working on. With an agile team, we are all acutely aware of what we are working on so the only updates that the team needs is on how the company is doing, and I provide that information on demand.  Another great agile benefit.

Staff Meetings

This would be the wrong outcome of Agile

 

 

While I did my MBA this was definitely one of the outcomes.  However, working on an agile team has changed this. You have to trust your team. You quickly learn that everyone is professional and trying their best to do the job.

group projects

Agile from the eyes of a 20 year PMP veteran

My world has changed, for the better.  When I first was introduced to Agile it was just a buzzword at a large company. “We need to be more agile. We need to set up agile teams.” Okay, sounds easy. Let me put together a project plan for that. It turns out that we were just paying lip service to an idea that someone told the CIO about. When we had to actually do agile, there was no support, no plan, no idea of what we were supposed to be doing. I had a team of 6 developers working on web projects that reported to me.  A great opportunity to actual put an agile team in place, however were told to “Keep Calm and Carry On”

Keep-calm-and-carry-on

Fast forward a year and I’m now part of an agile company and working closely with an agile team. There are many differences, all of which take some getting used to.

Over the next several posts I will examine some of the major differences:

  • Leading from behind
  • Where does the work of the PM go?
  • No Project Plans
  • “Meeting Hell” removed
  • Visible, daily updated progress
  • “Requirements? We don’t need no stinking requirements!” (with all apologies to The Treasure of the Sierra Madre)
  • Weekly/Monthly Status reports: guessing versus actual metrics
  • A reason to invest in 3M -> Post-it notes everywhere

The thousands of dollars spent on attaining my PMP are not necessarily wasted, but they are diminishing in value for my future.  Sure I can still talk the talk, but I no longer want to walk the walk.  In the words of Pumbaa from the Lion King “You’ve got to put your behind in your past”, basically it is time to move forward with something that is better, stronger and faster in delivering results.

 

© 2017 Lee News

Theme by Anders NorenUp ↑