#NASA Agile Mindset

One of my favourite websites is Digg for the variety of interesting articles that they link to. In reviewing the list of articles today, there was a very interesting article that immediately struck a chord with discussions I have heard about being Agile and having an Agile Mindset.

The Problem

It turns out that a problem was encountered a few years ago with the Constellation Programs. The Ares 1 rockets were encountering excessive vibration that made it impossible for the astronauts to read the new digital displays. The last time NASA had to test for vibration problems was 50 years ago with the Gemini program with all their analog dials. So they enlisted the same group that did the testing for the Gemini program and tested vibration issue with the Ares 1 rockets.

It turns out that the astronauts were experiencing 4 G’s at the point that the solid rocket boosters were burning down. On top of that, the vibration caused by the solid rocket boosters burning down added another 0.7 G’s. It turned out that even the 0.7 G’s made even the largest numbers illegible.

It was at that time that NASA realized that they had a huge problem and started to investigate how they could possible correct the problem. They were investigating counter-measures to offset the vibrations and make the controls readable once again.

The Solution

In an act of pure problem solving genius, someone had the following idea:

“Instead of spending millions of dollars to ensure the astronauts are not experiencing excessive vibrations, what if we just synchronize the astronauts vibrations with the strobing of the display so that the reading would be legible?”

Awesome.

They went through a couple of iterations. The first attempt just tried a strobing frequency of 12 Mhz as the chair the astronauts were in vibrated at about that frequency. But in reality, the chair could be vibrating between 10 Mhz to 13 Mhz. So although it was better, it was not good enough. So finally they attached an accelerometer to the chair that would be used to exactly synchronize the frequencies between the chair and the display. It was perfect.

An Agile Mindset

Besides this being an excellent example of problem solving, I felt it also was a prime example of having an Agile Mindset and being adaptable. I firmly believe that a crucial part of Agile is adapting to the frequency of the project, team, and client. Rather that creating counter-measures to modify the external frequencies (Imposing practices), I feel Agile is about modifying practices and processes to put them in sync with the realities of the project. We all know there isn’t a one size fits all solution out there, but I thought this story was a great example on how adaptation is so important.

Recommending any practices without first being in sync with the project, team, and client is terribly risky. But once you are able to adapt and are in sync, then possible changes can be suggested and implemented to deliver more value to the client.

You can find the full story here.

#Agile Project Charter

With the current project I am working on we discussed how we can make the Project Charter or Project Kick-off activities much more Agile. We are proposing to use new Agile methods and want to enhance our communication and allow team members to easily understand what they would be doing on the project.

On other projects I have been part of, these Project Kick-off activities involve a meeting that can have a lack of energy and enthusiasm. The Project Charter document is typically reviewed that details the roles and responsibilities of the clients and team members. In many cases the document is overly textual and team members come away from reading the document not understanding what a typical day or week will be like on the project. Even when a meeting is held to review the document, the content can still be somewhat generic and not allow people to understand their place on the project.

An Idea

After thinking about this problem, I was reminded I heard these issues and comments before. I think we have all heard these comments many times about User Requirement sessions that reviewed a large textual document and then scheduled excruciating meetings to review the documents in detail. And then at the end of those sessions, the clients still didn’t have a good understanding of what those requirements meant to them personally and understand what their place in the solution was.

So I thought if User Stories are successful in grounding clients with the solution and enhancing communication on User Requirement by making them personal, why not try the same with Project Team User Stories to describe the team member’s project interactions in the same way?

Project Manager Example

Here is an example of what a Project Manager’s interaction could be. There are some heavier weight processes and documents that would not be used all the time, but I thought it would be good to include them so I thought the entire process through. I’m still working on the wording of each story, but I think you can get the intent of the idea.

As A I will When So That
Traditional Project Manager Create the Project Schedule using traditional methods At the start of the project We have a realistic starting point and plan for the project
Traditional Project Manager Complete the Project Initiation Checklist At the start of the project All required tasks are completed
Traditional Project Manager Hold the Client Project Charter Meeting for the Client At the start of the project All Clients understand their role and expectations on the project
Traditional Project Manager Hold the Development Team Project Charter Meeting for the Development Team At the start of the project All Development team members understand their role and expectations on the project
Traditional Project Manager Create the Risk Register At the start of the project To derive the Risks, define the mitigation plans and incorporate the Risks and mitigation plans into the project schedule, and to communicate the risks to the stakeholders
Traditional Project Manager Create the Issue Register At the start of the project To document the Issues, define plans to address, and manage to the due dates.
Agile Team Member Review and understand theUser Story Map Before the first Iteration So that I understand the plan for the project and the content of the work required.
Team Member Review key documents when they are produced

  • Business Requirements
  • Solution Architecture
  • Active Architecture
  • System Requirements
  • User Story Map
  • Test Strategy
Before the first Iteration and throughout the project So that I understand the plan for the project and the context of the work required.
Agile Project Manager Create the Iteration Plan Before the first Iteration So that we can transfer an Initial Plan to a Manageable plan.
Agile Project Manager Create the Kan Ban Board Every Day The status of the project is available to everyone
Agile Project Manager Create the plan on the Agile Project Management Tool Every Day The status of the project is available to everyone
Agile Project Manager Update my tasks on the Kan Ban Board Every Day The status of the project is available to everyone
Agile Project Manager Update my tasks on the Agile Project Management Tool Every Day The status of the project is available to everyone
Agile Team Member Provide my update at the Stand-up Meeting Every Day The entire team is aware of what I am working on an any issues I may be having
Traditional Project Manager Create the Status Report Every Week The status of the project can be communicated to the stakeholders
Team Member Update the Risk Register Every Week To update the Risks, update the mitigation plans and incorporate the Risks and mitigation plans into the project schedule, and to communicate the risks to the stakeholders
Team Member Update the Issue Register Every Week To update the Issues, update plans to address, and communicate due dates.
Agile Project Manager Hold the Iteration Planning Meeting At the start of every Iteration The team can jointly determine the content of the next Iteration.
Agile Project Manager Hold the Planning Poker Meeting At the start of every Iteration The team can jointly estimate the User Stories in the next Iteration and refine the requirements.
Agile Project Manager Hold the Mid-Iteration Planning Meeting At the middle of every Iteration The team can jointly determine status of the Iteration and determine if adjustments need to be made. If appropriate, the mid-week status can be communicated to Stakeholders. Risks and Issues will also be reviewed.
Agile Project Manager Calculate the Iteration Velocity At the end of every Iteration We can plan a reasonable workload for the subsequent iterations.
Agile Project Manager Hold the Iteration Retrospective At the end of every Iteration The team can provide feedback and improve for the next Iteration.
Agile Project Manager Hold the Demonstration Meeting At the end of every Iteration The client can present the content of what has been completed in the last Iteration.
Traditional Project Manager Hold the Project Retrospective At the end of the project Lessons learned from the project can be captured and incorporate into future projects.
Agile Leader Promote Collaboration over Documentation Continuously Miscommunication and Documentation waste is minimized
Agile Leader Promote Rapid Discovery Event Continuously We can quickly define the requirements in a collaborative way. Miscommunication and Documentation waste is minimized
Agile Leader Promote light weight Documentation Continuously Documentation waste is minimized
Agile Leader Promote frequent delivery Continuously True progress is shown and realized
Project Leader Ensure key documents are produced when required

  • Business Requirements
  • Solution Architecture
  • Active Architecture
  • System Requirements
  • User Story Map
  • Test Strategy
Continuously Required project and corporate memory is created
Agile Project Manager Focus on managing issues and risks not tasks Continuously I facilitate progress on the project not documentation
Agile Project Manager Document all scope changes that cannot be accommodated Continuously I facilitate the communication of scope changes to the project to all stakeholders
Agile Project Manager Defer all setting of priority decisions to the client Continuously We work on the true priorities of the client.
Agile Project Manager Promote the use of Visual Project Management and Agile Project Management Tools Continuously We communicate relentlessly the status of the project to the project team and the Stakeholders in a graphical and easy to consume manner.
Team Member Seek collaboration and consensus on all decisions, but understand that schedule decisions are the responsibility of the Project Manager Continuously Decisions are made striking a balance between collaboration to seek all sources of information and efficiency to make difficult decisions when required in regards to schedule.

Summary

I’m excited about the idea. I think we need to be careful so that people understand that they still need to have an Agile mindset and these are guidelines only. But with the right leadership, I think this format could really assist in the Agile project Kick off.

Seven traits I look for in #Agile teammates

There are seven traits that I have seen in the great number of teammates on Agile projects that I now look for when I am asked to recruit or add to Agile project teams. Most of these could also apply to traditional project teams, but I have found their absence seems to affect  Agile teams even more. I thought it would make for a good post to share those items. Please let me know your thoughts on my list, I am sure there are other items I have not mentioned:

Without further ado:

1. Profound Empathy for the client

It is become common for people to state they are ‘client-focused’ in resumes and discussions with other people, but I am talking about a client empathy that is much more profound. I have seen ‘client-focused’ individuals just state ‘oh well’ or state reasons when a requirement is missed or a defect introduced that has caused much pain to the client. The type of Profound Empathy I have seen in awesome Agile teammates are ones where the teammates build a friendship with the clients and feel a true relationship to the client. (the client is not different from them) The best ones even have feeling of remorse as issues arise. You don’t want these feelings to be all-consuming for teammates, but when teammates go from exclaiming ‘oh well’ to ‘lets figure out not to have this happen again to Murray’ we are definitely on the right track.

2. Lack of an Ego

In an Agile project, we are frequently going to change our roles and duties based upon what is needed. It is much harder to have teammates who are only Project Managers or Developers or Business Analysts. I have heard some people state ‘I just write what the specs say’, ‘I just write down what the client says’, and ‘I just assign the tasks’. I refer to this as Ego as I think the people have identified more with their roles than the client, problem, or solution. We need people to do whatever it takes to get to end of job. That mean an experienced Project Manager may need to learn a new testing framework and implement it or an experienced architect may need to write basic reports because that is what is required.

No work is beneath anyone, and people really enjoy working on whatever helps to move the project forward.

The important distinction here is that people sometimes will work on other tasks but then be unhappy about. People without Ego honestly love to work on whatever is needed to move the project forward.

Why is this? Because they….

3. Desire to learn and try new things

Have a real desire to learn and try new things. They don’t want to learn a skill and rinse and repeat for the rest of their careers. When they are asked to learn a new skill and operate in a new role they are excited for the opportunity to learn and expand their skills. They read up on topics they enjoy in their spare time, they tinker with new technologies and methods, and are eager to then try to apply what they have learned.

4. Are collaborative in problem solving and decision-making

One of the interview questions I love to ask is:

‘What is the toughest problem you have solved and how did you arrive at the solution?”

I find you get a good read on a person’s problem solving skills and their collaborative tendencies to solve problems and make decisions. I have been on many projects where individuals sought input from teammates not because it was required, but because they honestly wanted that feedback as an opportunity to learn and improve. They really understood that every single person has a set of experiences and expertise that can offer something.

Now the important distinction is that they are not afraid to make a decision, they are just collaborative in gathering the information to facilitate that decision. They still may have to make a decision that not everyone agrees with.  It is really about collaboration and not consensus.

5. Desire and ability to help grow the team

Not everyone is going to have a wealth of experience. You need the teammates who welcome lesser experienced individuals and relish the opportunity to share their experiences with them. It is about all of us getting better. It really is discouraging when I hear people mention that someone is going to slow them down or may place the project at risk because of their inexperience.

I absolutely love teammates who look for opportunities to help to grow their teammates. They understand that the project is only a short-term situation and building awesome teammates will help us all in the long run. And even more profoundly, they honestly like to teach and help people reach their full potential. That is awesome.

6. Problem Solving Talent/ Talent with a diverse set of skills

One item I don’t see mentioned a lot on these lists is talent. Even if someone has the five traits previously mentioned, they still need to have the talent and skills in the roles that are required. Usually I find that the people who have been great teammates are all great problem solvers and they have a primary expertise with the ability to have secondary or tertiary expertise. (Or the ability to gain this expertise rather quickly) This could be in development, analysis, testing, database design, project management (eek!) or a multitude of others.

The important thing is that beside the great teammate traits listed above, each teammate has to bring talent to the project to contribute. (at whatever level is appropriate)

7. Initiative

And the last item is initiative. I’m not calling it leadership as that term I feel sometimes goes against the concept of self-organizing teams. (Does a self-organized team really need to be led?) I like initiative as it captures the sentiment that every team member should feel comfortable showing initiative and contributing at the appropriate points in a project.

The important thing is you want everyone on the project to contribute ideas and not just feel that ideas are someone else’s responsibility. Of course it is the responsibility of the entire team to create the environment where people feel comfortable proposing ideas. But that is a topic for another post…