Agile Project Characteristics – Two Controversial Factors

In my last post I listed the Agile Dozen Characteristics and Practices that I felt were critical on all projects. In that list though, there were two characteristics that I did not expect myself and that may raise the eyebrows of Agile purists when mentioned. Before there is discussion on all the factors and I present the experience reports, I thought it would be of value to discuss the following two characteristics:

  • Developer to Designer Ratio
  • Team meeting estimates

1) Developer to Designer Ratio

Where to start on this one. The first immediately apparent item is that there is a difference between developers and designers. Yes, I would say that there is room for both of these roles and that I believe that perhaps all of the design and development activities can’t be pulled by any member of the team. I know this principle is tantamount to heresy in some of the Agile circles, but I believe that context is everything and there are no absolutes. Based upon the problem domain, team composition and solution complexity, there may be a requirement for a role that owns the solution vision at a very high level. Now this does not imply the creation of detailed requirements and architects and designers defining exactly what developers need to code, but merely implies that there is a role that provides the overall vision of the solution at a high level and then works with the entire team as they flesh out user stories to ensure that the solution remains cohesive and consistent. This designer can then also provide leadership in the architecting the automated test suite as well.

This has worked well on our projects. I’d really like to hear back from others on this concept…

2) Team meeting estimates

This was the other characteristic that I thought would be somewhat controversial. Now I firmly believe in Planning Poker and collaborative estimating techniques, but at the end of the day, no matter how the estimates have been created, a successful project must deliver to the estimates that they have made. ūüėź Whether this is a Traditional Project where estimates are defined at the task level through to an Agile project where User Stories and tasks are defined in points and through planning poker, eventually the execution must somewhat match the plan. (now matter how defined or loose the plan is) If this continues to happen through many iterations, the clients will get concerned and possible business plans that depend on the iteration outcomes may be compromised. To demand 100% meeting of the estimates is not feasible, but if the project consistently deliver less than 50% of the plan then some action needs to be taken. (Which could be to just be less optimistic and committing to less)

What do people think of these two more traditional characteristics? I’d love to hear feedback!

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:

http://borisgloger.com/2008/03/15/the-scrum-ball-point-game/

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.

http://agilewinnipeg.com/

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.

http://borisgloger.com/2008/03/15/the-scrum-ball-point-game/

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.

A System User Story Holy War? On a Saturday night? :)

I’ve struggled for a while with the concept of System User Stories. I know about the debate and argument that about only User Stories should be used to measure progress. And I agree 100%. I am not proposing that these System User Stories would¬†be used to manage the project and measure progress, but that they would be used to validate and confirm the system design and completeness of User Stories. In essence, they don’t remove the need for User Stories but are an additional activity and deliverable. I also feel they are an invaluable light weight model that documents System behaviour. I feel the lack of Application or System definition between¬†User Stories and Test Cases and Code is just too broad of a gap. There is room for a light weight model to fill that gap and ensure our solution has a high level of completeness and cohesion.

In my definition, these System User Stories are stories that define how the system components are interacting with each other at a high level. They have been attractive for me for primarily three purposes:

  1. To examine the full behaviour of the Application/System to confirm that the design and concept is full fleshed-out and complete.
  2. To create a light-weight model to capture the Application/System behaviour for communication through out the team.
  3. To confirm that we have the appropriate User Stories and tests across the entire Application/System.

One thing that has always troubled me about User Stories is that unless there an end-to-end light weight model of the System, we may have the system architecture and design affected when User Stories are worked on in later iterations if the functionality starts to diverge from previous understanding. Having a light weight model of System User Stories that we can then validate Traditional User Stories again greatly reduces this risk and highlights any areas not covered. I think the System User Stories have more value for complex systems. I am currently working on a very complex system, and I feel System User Stories were essential to ensure our design and scope was complete, correct, and compelling. Since the project is somewhat R&D we also lack a Traditional Product Owner so this task falls on the project team. System User Stories helps us to clarify this concept.

So given the fact that I think they are required, what format do they take?

What I have found to work is that they should be in total no more than 2-3 pages in total. Any more than that and you are going too deep and not just confirming overall design and consistency. You are actually doing requirement definition.

I also like the User Story type of format. It is complete and concise. The format I have used is:

As an [Domain Specific Language Component] I will [do a Domain Specific Language Action] when [Event] using [Domain Specific Language Components or System Components] 

The Domain Specific Language Components and Actions can be anything from true DSL Components or Actions to just the abstraction to the high level components used in the System or Application. It definitely should not be at a low-level. I also have broken these System User Stories into major features just for easy categorization and organization.

And then finally I renamed these System User Stories as System Grammar. I did this to shy away from the System User Story holy way and also to reflect that these rules truly are the grammar that the system uses to build its language of functionality.

System Grammar. I think there is a place for it.

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…. ūüôā

A Testing Phase – I just can’t quit you!

Finally I’m going to write about the problems I have had moving away from a sequential testing phase. I got side-tracked with some Monster analogies, but before I move on to discuss any other topics I need to fulfill my promise about writing about this.

To summarize, no other concept is personally easier to state and harder to do than a sequential testing phase. Even when I am coding or creating, my mind always thinks about creating sufficient inventory to then make the context switch to then test. Even though I know this is incorrect and I am losing quality and building inventory by doing this, I seemingly can not help myself. I was thinking about why this is and I may have a theory.

I wonder if this default behaviour on our projects is due to how we were educated? All through out our years we had the pattern of building up a sufficient inventory of knowledge in classes and then having a large test or two to validate that the knowledge was indeed mastered. I think back to university and my Mathematics exams worth 90% of the grade, the ultimate big bang approach. No concept of failing fast in those courses. Sure there was some assignments to practice, but even that was not consistent across all the courses. Ultimately most of my courses after Junior High had an exam of at least 60%. And of course the problems that caused were very similar to project issues:

  1. By the time you know there is an integration issue it is too late to do anything about it.
  2. You cannot correct mistakes early so if something is misunderstood the number of mistakes is huge.
  3. These large tests, don’t provide opportunities to learn. They only provide judgement.

This last sentiment has stuck with me the most and I remind myself of this fact to ensure I test as early as possible. I remind myself that the noble purpose of testing is learning, not judgement. With most traditional projects, the testing phase is almost viewed as a judgement being pronounced on the project declaring  whether it is successful or not. Almost like we are grading the project and determining if it has to go to summer school. We need to fundamentally shift our focus in testing to be that it is an opportunity to learn and not an opportunity to judge.

When you do this shift, something very interesting happens. The value of a Quality Assurance Departments and Testing groups lessens greatly. Those structures are all about judgement. If testing is about learning, then the people conducting it only naturally should be the ones that will learn the most! And that would be the developers and clients. (Hopefully together!)

I believe our educational system has now moved to more frequent, smaller tests to ensure that the tests are about learning, not judgement. It seems only now has our Information Technology projects also understood that it isn’t about judgement.

I would propose that rule #1.a of Software Development should be:

‘Thou shalt test the deliverables before each and every status report¬†is given and status meeting is held’ (this would be daily but weekly at the latest’)

This would ensure that testing is not a separate phase and that testing really is a learning activity by being integrated in the entire lifecycles of the project.

And really, how can we report on status if we haven’t tested????

Any guess to what Rule #1 is? Share your thoughts and I’ll tell you mine on my next post.