Agile Experience Reports – The Agile Dozen

My main purpose for this BLOG was to try and share some personal Agile Experience Reports and get discussions going with others on what worked and what didn’t work. My first challenge was to create a framework where some sense could be made of my personal project results.

When I compiled the list of Agile practices that I feel are important to projects, I was worried about how any patterns could emerge with that many factors. And I was right. I had compiled a list of 42 characteristics and practices that covered the Project Team, Project Planning, Execution, Requirement Gathering, and Development activities on the project.

What I did next was look at those 42 characteristics and practices and whittle it down to 5-10 Agile practices that I believe are really key to project success. Unfortunately, I could not get it below 12. So I was stuck with the Agile Dozen.

Next was the step to validate that those practices were indeed a true indication of project success. And through the projects reviewed so far, they have held.

For my upcoming Agile Experience Reports I’ll share how well we followed all 42 characteristics and practices on a rating scale of 1-5. But I want to caution that I am not viewing this rating as:

  • An Agile scorecard
  • An Agile Maturity
  • An Agile report card

I think those constructs cause teams to focus on the wrong things. Namely, getting a good grade rather than project success, client success, and continuous improvement. I created this framework to help myself understand what practices really contributed most to project and client success and help me to improve and focus on the right practices.

In the next BLOG post I’ll discuss in details the Agile Dozen and my rationale for including them. For now, here is the list of the Agile Dozen..

  • Team Experience (Technical & Domain)
  • Developer to Designer Ratio
  • Embedded Engaged Client
  • Team Continuity
  • Team Estimating
  • Automated Tests
  • Team meeting estimates
  • Daily stand ups
  • Retrospectives
  • Iterative Delivery
  • Epics, User Stories and Product Backlog
  • Continuous Integration

Then I’ll provide some context on where these characteristics existed and practices actually worked on projects and share lessons learned.

I hope you will find this interesting. I tried to find information like this when I was starting out and I could not find it very easily.


Agile Team Building – Apollo 13

We were talking the other day in my new project team about various team building activities. It was mentioned that some people have not seen Office Space, so this is spurring an impromptu screening to alleviate this oversight. ūüôā We then talked about other team-building activities that our teams at Protegra have done. They ranged from innovation games, to magic eight balls to cowbells. Fascinating discussion as I was not aware of how each and every team found a different and valuable way to build their team.

I mentioned that the team building I wanted to try on the next project was a movie that inspired me on leadership, team work, and problem solving. That movie was Apollo 13. Fantastic acting and storytelling, but I was enthralled of the enormity of the problems and how they solved them. Now to be fair, there are some aspects of the problem solving that wasn’t Agile. (Such as being overly directional and Smoking. Did everyone smoke back then?)

But there are five lessons I take away from that movie than can inspire any team:

1) Manage and Lead by end state

Throughout the movie after the accident happened, the problems were always presented to the team in the form of end-state objectives. We need to get those Astronauts home safe and sound. It was up to the team to determine exactly how to do that. It wasn’t about telling them what tasks to do. It was about stating the objective and letting them use their expertise.

But Flight Director Gene Kranz was always there to guide the discussion if they started to digress on what if scenarios and things outside of their control. Very aligned with Agile to empower your team to solve the problem and having the Project Manager just guide the process.

“Let’s work the problem people. Let’s not make things worse by guessing”

2) Have your client co-located!

Boy, bet you didn’t see that one coming! I think the major success factor was they had Ken Mattingly to assist them in testing how they could power up the Command Module successfully. (Ken Mattingly was the Astronaut that did not fly due to a suspected case of measles) Classic example of having a client co-located. Ken Mattingly was a pilot that knew all the requirements to fly that spacecraft home and the conditions they were under. And in a true moment of genius he refused to use any item that they themselves did not have on board. He even requested that the environment in the simulation Command Module set to the exact light and temperature they were encountering on board. This was critical to ensure that his solution was a solution that would hold up. Without this co-located client insisting to operate in the true working conditions, I’m not sure a solution would have been found. It also raises an interesting point that your co-located client needs to be a decision-maker, expert in the business domain, and an expert in how technology will be used on the front line.

3) Create an atmosphere of safety to allow people to contribute

Although Gene Kranz (Played by Ed Harris) was a strong cup of coffee, the environment they operated in was still one where everyone could offer their opinion and challenge opinions. Good teams find a way to create and maintain this atmosphere so that ideas are cultivated and grow. The sessions they had to solve the problems had almost everyone speaking up and offering ideas.

4) Care about the success of the Project. Take it personally

Gene Kranz had the following quote when asked about the possibility of losing Astronauts by the media:

“We’ve never lost an American in space, we’re sure as hell not gonna lose one on my watch! Failure is not an option.”

This quote has always stuck with me. Although some may say it is easier to be passionate in a situation where lives are at stake, I always find the best teams have found a way to have their team members genuinely care about the success of the team AND the success of the client and take it personally. This care and concern needs to be encouraged on projects and although all team members need to nurture this, it sometimes falls on a couple of team members set an example. These do not need to be your leaders on the project. In fact it is better if they are not people in the leadership roles.

5) Lead by Attitude

All through the movie Gene Kranz was unwavering in his confidence to the team even though I am sure he had internal doubts. This allowed everyone to have confidence in what they were doing and just ‘work the problem.’ Without this confidence, valuable effort may have been spent elsewhere on things that didn’t help to solve the problem. I think one of the most valuable things a leader can do is to lead by attitude and ensure the confidence of the team is high.

Check the movie out if you haven’t seen it…

Goldilocks and the three Project Managers

At Iteration 1 of the Agile Winnipeg User Group we were doing¬†the Agile ball game exercise. I won’t go into details here, but details can be found on Boris Gloger’s Blog by following this link:

For this exercise we appointed one person to be an observer for each team. This observer watched the proceeding and then made comments in the retrospectives. At the end of the session, it was subtly postulated/proposed that the Project Manager in Agile could actually be fulfilled by playing this observer role.

That statement bothered me for a while. I am not a proponent of a directional Project Manager, but I do believe they offer more value than just observing, So here we are with the three bears analogy:

The first Project Manager – Too hot

Well, we all know the first Project Manager was too hot for everyone’s liking. This first Project Manager is indeed the directional, traditional, micro-managing Project Manager we see in our past experience. This Project Manager is the Military Leader that is leading all team members by defining the plan at a very discrete level and then directing the individuals to execute that plan. This Project Manager is not at the Military General level as they typically do not contribute towards strategy. They only execute the plans that have been previously decided as the realization of strategic objectives.

This analogy works well¬† as it fits well with the traditional Project Manager not being concerned with value. They don’t have the extended awareness of value because they were not involved in the strategy creation. All they know is to execute what has been previously decided.

The second Project Manager – Too cold

The second Project Manager is somewhat too cold for my liking. Given that we have swung away from the traditional Project Manager for very valid reasons, I think we have thrown the baby out with the bath water. By labelling the Project Manager as merely only an observer, we have missed out on a great opportunity. I think it is a delicate balance to retain the additional value that a Project Manager role typically brings while still creating an atmosphere where a team can self organize.

But what are these skills that a Project Manager uniquely has more so than others? Well I am glad you asked. I would argue that a Project Manager has these additional competencies:

  1. Confidence to question – to ask why and to seek justification
  2. Comfort in conflict/Negotiation – to negotiate in the case of disagreement
  3. Workshop Facilitation – to facilitate all workshops
  4. Process Steward Рto create the right process with the team and then govern the process

The third Project Manager – Just right

So if a Military Commander is too hot and an Observer is too cold, what is just right?

A True Agile Project Manager РThe Referee

But wait, isn’t this just an observer? I would suggest that the observer was not required¬†to¬†have these other competencies. How does the Referee analogy provide this value you ask? Please indulge me by letting me use the analogy of an National Football League(NFL)¬†Referee.

Foremost, the Referee is a student of the game and has contributed to the rules of the game. The Referees have detailed domain knowledge of the process (Rules of the game) and I would argue they also have domain knowledge of what the Offence (Technology), Defense (Business Domain), and Special Teams (Requirements) are trying to achieve. The Referee now can let the teams play the game (Self-Organize and deliver scope), but challenge the play when individuals over step any rules that everyone has agreed to. The Referee then is an expert in conflict resolution and facilitation.

For experienced teams, the Referee probably provides less guidance than he or she does for new teams. Once teams have worked together, they really manage the project themselves and require little guidance.

Ultimately, the Referee should be a former player. This will grant the Referee Domain Knowledge and allow him or her to challenge the play at all times.

In fact, I would argue that an Agile Project Manager must be a current or former player. Thoughts?

My final comment is something that anyone playing sports can probably attest to. I would estimate that 90% of a GOOD Referee’s time and effort is not spent calling infractions, but rather encouraging proper behaviour while the game is being played. Now that fits into the role of an Agile Project Manager!

Agile Winnipeg User Group is alive!

I was fortunate enough to attend the Inaugural Agile Winnipeg User Group meeting last week and the presentation given by Steve Rogalsky and Doug Kok was awesome. Over 60 people came out from a multitude of companies throughout the city as well. It was a nice surprise to see how many people are interested in Agile.

For those of you that could not attend, here is the link to the site. It has the presentation slides and a link to sign up for future meetings as well.

The presentation doesn’t have any information on the ball point game though. If you want details on the game itself, please check out Boris Gloger’s Blog.

I’d love to see more attendees at the next session. Let us see if we can make¬†Winnipeg an Agile leader like Vancouver!

You might be a Project Management Redneck if….

With Kudos and possibly apologies to Jeff Foxworthy,¬†I was thinking a good¬†discussion might be the warning signs when you might just be a Project Management Redneck and aren’t really buying into Agile. But what is a Project Management Redneck?

A sample definition might be..

Project Management Redneck

A slang term, usually for a Traditional Project Manager who is conservative, risk-adverse,  controlling, non-collaborative, mistrusting of the client, and a methodology fundamentalist. This term is generally considered offensive. It originated in reference to the colour of the status of their projects and in some given circumstances the colour of their complexion during User Acceptance Testing.

So without further ado:

You just might be a Project Management Redneck if…

1. You are using MS Project

OK, all kidding aside this really has to be the number one entry. I think we have all been there and tried to manage our first Agile project using MS project and faithfully tried to enter a Work Breakdown Structure into it. Nothing against MS project, but it really is not the easiest tool to oversee a project. (Hey, I didn’t get struck by lightning!) All of the metrics it produces really do not apply for agile projects. Most importantly the managing of the¬†project is something the entire team does. Not the job of one team member using the one license of MS Project.

Now you actually could use the tool to manage user stories, but why? Seriously, We just thank MS Project for helping to show a better way and MS Project should just be put in the bin with other useful constructs of the past like 8 tracks and projection TVs.

2. You do not have a Kan Ban board

Closely related to using MS Project, if you don’t have a Kan Ban board to measure your progress and the Kan Ban board isn’t the barometer of your project, then you really are a Project Management Redneck. The Kan Ban board needs to be the social hub of the entire project where all the daily stand ups and status discussions are held. It also needs to be out in the open so that everyone knows the status and can quickly see the progress.

You also may be a Project Management Redneck if you copied a Kan Ban board and didn’t modify it. This has got to be one of the basic premises of Agile. Instead of just copying, we need to embrace change and risk taking.

Traditional: Copy and Paste

Agile: Copy and Progress

3. You did not use Planning Poker to estimate (or other collaboration tools)

Collaboration is very critical to not being a Project management Redneck. If you segment deliverables assign them to roles and have deliverables created in isolation and seek consensus only for sign off and not creation, you ARE a Project Management Redneck. Very little¬† created in isolation is of¬†higher quality. As a Project Manager if you feel that you only need to be responsible for the budget and not understand the functionality, business domain, or technology…. then you are a …well you get the idea….

A great example of this is the exercise of planning poker. Almost every project manager will bemoan incorrect estimates and the Redneck Project Managers will expect that correct estimates will be given by different people at different times with different experience levels and almost no context. (sometimes they even create the estimates themselves or hold teams to estimate made by other people)

Velocity is your friend!

4. You take comfort in a User Acceptance Testing¬†phase and you have ‘testing’ resources

User Acceptance Testing, the last refuge of the Redneck Project Manager. If you take comfort in a large UAT phase and believe you have to have resources that only test, you are a Redneck Project Manager. This big bang implementation of testing is a thing of the past. Lets all agree that nothing good ever accompanies a big bang. Usually it is accompanied by fire, shrieks of pain, heat, and of course defects.

Testing needs to proceed the actual development on a project. Testing needs to be incorporated across the entire duration of the project and across multiple team members. In this way everyone has shared responsibility to the testing and quality of the entire solution and it isn’t just the responsibility of that testing team that joins the team late.

And Testing must be automated!

Once you integrate the testing into the daily cycle of the project and have testing preceding development, you can achieve projects with Zero defects.

5. Your team and client is not co-located and you like it that way!

Co-location is paramount to the success of a project. If you like to have an office and be separate from the team and spend quality time with your project plan, then you are a Redneck Project Manager. You have to be with your team and be part of the discussions. Every project manager complains about not knowing of issues on the project. Trust me, if you sit with your team you will know of every issue…

The client also needs to be co-located. If you feel that having the client co-located will result in more changes you are correct. But ultimately this will result in a better solution and client satisfaction.

Traditional Project Managers manage the plan, Agile Project Managers help the team deliver value to the client.

Number One rule of Software Development – Its the People Dammit!

As promised in my last post, this post will be all about what I believe to be the number one rule of Software Development. Now there are many factors that go into great Software Development projects and products but ultimately I think the best results have come from the same factor. The people. But specifically it is a certain type of person and focus in those people.

Protegra is very focused on finding the right people to fit into our team because we understand that at its heart Software Development is a social activity. Like any other social activity or team sport, I believe the most important attribute is the drive to strive for continuous improvement. If you strive to be better than you were yesterday, you won’t have to worry about being better than other people. That will eventually take care of itself.

A phrase a fellow Protegran used was ‘Student of the Game’. If you have Students of the Game, I have no doubt the your project and your company will succeed. Students of the Game bring the following skills to bear on a project:

  1. No personal Ego
  2. Relentless pursuit of new ideas and innovation
  3. Fearless approach to trying new things
  4. Constant focus on getting better
  5. Unquenchable thirst for knowledge
  6. Deep involvement in the community and mentoring
  7. Contagious & Passionate approach to all aspects of work
  8. They are Brave
  9. Client Focus

This Student of the Game approach is core to the Agile approach. And also at its core they must trust that co-workers at all levels have their backs as they are brave. This is crucial. If this does not happen the risk taking stops and the Students of the Game leave for another company or just execute in a safe manner that never challenges the status quo.

But you may ask, ‘Terry, if I have these students of the game, won’t I be adding risk, constant change, and constantly gold-plating solutions?’ These Students of the Game must be students of the technology, process, and business acumen. We are not just talking about the technical Students of the Game. These Students of the Game need to be balanced across the facets of the project.

Just like anything else, these passions also need to be moderated. And the most important moderation is that all these improvements need to be tempered and grounded in value for the client. As we pursue these ideas, if our focus is solely on value for the client we won’t be led astray. We should never be doing anything just for the sake of trying something new. It has¬†to have expected benefits for the client.

So how do you find these Students of the Game? They will¬†be wearing the white hats…. ūüôā

User Story Mapping – Oscar for best presentation ever!

I now know why a colleague of mine at Protegra has been raving about this User Story Mapping presentation from Jeff Patton. I have read up on the concepts but until now did not fully review the presentation.

Simply put, this is the best presentation I have ever seen both in style and content. Awesome.

360 Performance Feedback “in the round” – Abolish the EAT Phase!

performance feedback is one of those issues that seems to confound Traditional and Agile projects alike. Even with Agile projects, sometimes the Performance Feedback gathering is left out of the retrospectives. Frequently the Performance Feedback is left to the end of the project or at major milestones to gather feedback.

I have worked at Protegra for over 8 years. Protegra is an extremely collaborative company that embraces the principles of Lean (& Agile), but we have also struggled to capture high quality, timely, and meaningful information to assist in Performance Feedback. I played the role of Delivery Manager for over 4 years and we frequently struggled with trying to counsel people in regards to Performance Feedback for whom we had little information on. Since we are a project based company and we fundamentally do not believe in supervisors or managers, we also did not have roles that were solely responsible for gathering and delivering feedback. It was the responsibility of each and every team member to do this. So what did we do?

Just like every improvement, we did this through a series of small improvements. Rather than go through each improvement, let me recap where we are now. To summarize, this resulted in three areas of change:

1) Reinforce the terminology of Performance Enhancement to fit the intent and communicate the reason behind gathering the information

We have found that language is very important to communicate the true value of a process. Many people viewed Performance Feedback as being required for compensation. We re-inforced the language of Performance Enhancement and stressed it is about helping people improve on the competencies they want to improve on and that are  important to the role. It is not a cookie-cutter approach where we fit people into a role description and rate them accordingly. This was a fundamental first step on the change. (And it is a continuous effort)

2) Create a Technical Performance enhancement Framework

The next step was perhaps the most difficult. We created a framework that recognized the true competencies of our culture, roles and team members that we are aware of. An important distinction was that these competencies were for our culture and roles and¬†not positions. We don’t have positions at Protegra, but rather a variety of roles¬†anyone can play on projects. Unlike other Performance Enhancement systems, this is a constantly evolving collection of competencies as new competencies and skills become valued¬†at¬†Protegra. Another key aspect was to ensure that the competencies also had objective criteria to be able to help assist people in the evaluation of the competency. Instead of just stating:

“Mike is a good .NET developer and has achieved an intermediate level of Programming expertise”

The competency framework will prompt the reviewer to evaluate competency aspects we incorporate in the terms “good” and ¬†“intermediate level”. For example, for the role of a Software Developer on a project these would involve providing grades on such¬†aspects as:

– Use of SOLID design principles

– Use of Standard Design patterns

– Creation of Change tolerant code

– Creation of Automated Test Cases and test coverage provided

– Among others

This level of information is gathered on less frequent basis due to the amount of effort required. It is very important, but we still needed to capture information quickly and frequently that could feed into this structure.

3) Hold Retrospective Performance Feedback sessions “In the Round”

The most important aspect we then implemented was holding¬†Performance Enhancement sessions “In the Round” as part of each and every retrospective. Unless the Performance Enhancement is incorporated into the process of the project, it will be left behind. Although people were apprehensive at first, as they become comfortable with the process and more comments and feedback was gathered. To be honest we have only recently implemented this process but the results are quite astounding. In this setting we also asked people to consider the following questions when evaluating their teammates:

– What can they do more of?

– What can they do better?

– What can they do less of?

– What can they do differently?

It is still a work in progress but the results are going in the right direction. I believe our approach again aligns with the Agile approach.

The largest realization I had was that holding Performance evaluation Sessions at the end of a project or during a considerable period of time is EXACTLY like having a User Acceptance Testing (UAT) phase. But we were rather having an Employee Acceptance Testing (EAT) Phase.

We need to attack the elimination of the EAT Phase is projects like we have eliminated the UAT phase. This validation of team members needs to occur daily just like our testing!

Building a better monster – Naturally Agile

When we last left our intrepid Project Manager (Evil Scientist) he was fighting off the hordes of rioting Business Users and negotiating change requests. Not a good scene and something that could certainly be avoided.

It turns out that the answer to how we can build a better project has been done forever by nature. Nature in itself is intrinsically iterative and abhors big bang implementations. (except for ‘the’ big bang, but that is a topic for a different blog entry)

To start at the beginning, let us review what the evil scientist was trying to do. The very objective of the project had two essential criteria:

  1. To create life
  2. To have this new life follow his direction

Each of these essential criteria has a complementary concept in the Agile world. Let’s discuss both of them in sequence.

1. Creation of Life

As you can probably surmise, my analogy for being able to manage a project is exactly how nature creates life. The creation of life project has the following external milestones:

  • Visioning at Conception
  • Implementation at Delivery

Now there is an immense amount of work being done between these two external milestones and thanks to modern medicine we have more of an eye to this progress than previous generations. Although the creation of life is a 40 week project (for humans), the following systems are initially formed at the following milestones:

  • Nervous System – 8 weeks
  • Circulatory System – 4 weeks
  • Skeletal System – 6 weeks
  • Respiratory System – 6 weeks
  • Digestive System – 6 weeks

As you can see, although the implementation date is far in the future, nature really delivers initial functionality on all major sub-systems¬†8 weeks into the project. (I know I am hugely simplifying this, but I’m hoping you will cut me some slack. :)) So by 20% into the project nature has an end to end prototype (pun intended), that nature can then add subsequent functionality to before the final release. Some of this additional functionality is the refinement of these major systems which includes:

  • Full Skeletal Structure – 1o weeks
  • Hearing – 17 weeks
  • Breathing of Fluid – 28 weeks
  • Ability to¬†Suck Thumb – 28 weeks

One important piece of information is that from weeks 33-40 it is reported that there are no major qualitative changes. During this period there is just more refinement and ‘hardening’ of the baby. (And possibly some refactoring?)

Let me leave you with two questions:

  1. How much better shape would our projects be in if we had an end to end prototype built by the time we are 20% into the project?
  2. How much better shape would our projects be in if we were only hardening our solution in the last 20% of a project?

2. Project Management Style

The other comment I would like to make quickly is that the Project Manager style of the Evil Scientist is definitely ‘old school’. I fundamentally believe that the new Project Manager style is more of a parent. Now I do not mean this to imply that the child project is beneath the parent in knowledge at all. But that the Project Manager is meant to facilitate the learning and growth of the project. And by doing that the project will also teach the Project Manager. At the end we really do need to look at projects as not something to be led, but rather as something that learn, grow, and succeed.

Perhaps we should term this concept Embryonic Project Management? Should the 20% milestones nature uses at the start and end of the project simulated in a project?