The Agile Tribe

What's your role in an Agile team?

Author: Susan Akers

 This is an issue that many people face working in an Agile team particularly those in the role of Project Managers or Iteration Managers

Common questions around these two roles can be – 

  • Are they the same role?
  • Should the Iteration Manager just be someone from the team?
  • How much time should be spent on being an IM? Full-time/part-time?

To help answer these questions and more, the Agile Academy has produced yet another handy Agile in Practice Help Sheet on Agile Team Roles and an accompanying video of the same name for those who want a bit more information about the difference between being a Project Manager and Iteration Manager; as well as seeing what other roles should be part of the Core Team and Extended Team.

1 Comment »

Agile Australia through the looking glass

Authors: Robert McDonald, Belinda Lawrence and Wayne Allan

Some views and take aways from the recent 2011 Agile Australia conference.  This is what three people saw and heard.

Robert McDonald, Operational Reporting Analyst

“If there is word to describe what happened in the Agile Australia conference of 2011, it was ‘vibe’.
Being part of such a collection of ‘Can Do’, challenging, active and clever people, all intent on making the world a better place was fun. Some had the longer scaled up version which looked towards a bright future, while others shared their ‘tactical’ excellence.
Read the rest of this entry »

4 Comments »

People Issues and performance reviews – Team Leader or Iteration Manager?

Author: Steve Jenkins (Steve presented his talk at Agile Australia 16th June 2011)

My name is Steven Jenkins, I have had all these roles on projects, projects that were sized from just a few thousand dollar budget to millions of dollars over many months. I am currently the Iteration Manager (IM) within Suncorp’s Banking Platform Program.

This lightning talk raises two main questions. 

Firstly, with regards to managing people how does the Agile framework scale for larger projects and secondly how should the delivery team and the leadership team work together.

This talk may be a little Suncorp specific role but it relates to the relationship between project staff and line leadership no matter where you work.  I will explore the grey areas between these roles, the role expectations on each other and lastly some recommendations to improve  team cohesion and managing people dynamics.

I have 5 more slides and now less than 5 minutes, so let’s get cracking…..

For context, these are the roles within a major Suncorp project. 

This diagram makes the difference between roles look clear, however there certainly is cross over and grey areas between each role, especially when it comes to people issues and performance reviews.

For a simple definition:

Iteration Manager – people’s work load and work flow. 
Team Lead  – work’s people load and people flow. 

I am flipping these words around to show how closely related these roles are to each other but they both complete very different jobs.

Now let’s explore the people based issues where the responsibilities are ‘grey’ and where accountability and control need to be delegated to ensure that the team is ‘humming’ to its greatest potential.

As a IM I feel like a need to be a control freak.  Or maybe just an ‘out of control’ freak.  After being in both TL and IM roles,  the key source of frustration for me is due to the role accountability vs. control – the IM feels that he/she is accountable for the velocity of the project, but he needs to work closely with the Team Lead who controls the people.  It is these people who give the momentum, the momentum that delivers the project. 

The two roles are therefore linked, but how far along the self managing team vs. the reliant team spectrum is your team?

The next set of problems relates to relates to the teams self management skills, how well does a team really deal with human relations issues?  In my view it would take either a very special team or a team with HR mentorship to get through many of the personal issues that can occur, these could be issues such as intra-team issues such as ‘wars’ or inter-team issues such as work that has been committed to by the team leader.

Lastly, can the team leader comparatively rank, compare and provide valuable performance feedback to the individual staff member when he or she sits outside the team. 

The key for me is that the iteration manager becomes so close to the work that he or she potentially has the greatest micro view of what is going on with the people.  The danger is when the Team Leader doesn’t have a view of the work and the Iteration Manager doesn’t feel as though he/she has got the people control required to match off with the level of delivery accountability.

The team leader is expected to be a 7 legged beast.

  1. Culture Manager – Creates a safe environment, a culture where people can make mistakes and learn from them.
  2. People Manager – Improve team cohesion
  3. Resource Manager – Resources to deliver
  4. Emotional Quotient Manager – Senses performance breakdowns
  5. Continuous Improvement Manager – Helps identify improvements
  6. Public Relations Manager – Bridge between groups (speaker for the team to the rest of the company)
  7. Best Practice Manager – Sharing best practice from outside our team.

The IM is expected to be have the following people elements under their control.

  • The Team – track iteration’s progress (day-to-day work from people), report impediments relating to people, make sure iteration’s commitment will be fulfilled, point bottlenecks in the delivery process.

The Customer – act as gatekeeper, protect people from distractions.

The Iteration – plan team’s budget (ideal hours), help customer with prioritization, motivate team, owns iteration planning and retrospective.

The Project – form a group of people working together towards a common goal (they succeed or fail together); aim for productive and happy team members and a satisfied customer.

Reference: http://tomekdab.blogspot.com/2009/03/ive-recently-read-essay-about-iteration.html

The following recommendations work as well for the team leader as they do for the IM.

  1. Keep close to the people. This is only possible in small teams where you regularly talk to the people.
  2. Keep close to the motivation, what do your staff now want from their career?
  3. Keep close to the changes, challenge the status quo and mediocrity.
  4. Keep close to the strategy – What is changing in the business?
  5. Keep close to the project – TL and IM both need to stay involved in the project as a Coach/Mentor/Water Carrier- Boulder remover.
  6. Keep close to staff performance – this makes mentoring and performance review more credible.
  7. Keep close to accountability vs. control issues.  Who needs to be delegated control.
  8. Keep close to the buzz – IM and TL need to trust each other and talk regularly.

To conclude, great inter-role, inter-personal skills and a tight working relationship is required to make this double teaming of the TL and IM work. 

I would really appreciate your comments, suggestions, ideas and recommendations on how I might improve this talk or if you feel that I’ve left something out (remembering that I only had 5 minutes). 

If you want more formal information about where the IM fits into this thing we call agile, the Agile Project Management course is one of the courses offered by the Agile Academy which covers it well.  (Editor)

2 Comments »

The Evolution of Test Driven Developers

Author: Peter Sellars (Reprinted with thanks to Peter)

Evolution

Test Driven Development (TDD) since its rediscovery by Kent Beck in the early noughties has led to an evolution in the information technology developers of our species. So where on the test driven developer evolutionary tree do you or your developer kind sit?
Read the rest of this entry »

Leave a comment »

Why so little good Agile?

Author: Shane Hastie (reproduced from Shane’s blog)

Today I gave a talk at the NZ Government Testing conference in Wellington. I presented a case study about how the Farm Systems Division of Livestock Improvement Corporation have adopted Agile methods.

I told the story of Team Awesome (they choose the name themselves), how their practices have changed and the measurable benefits that have resulted from their new way of working:

  • Massive reduction in residual defects
  • Increased team satisfaction
  • Shorter time to market
  • Increased customer satisfaction.

Read the rest of this entry »

4 Comments »

Agile – in name only?

Authors: The Agile Coaching Community

“We place the highest value in actual implementation and taking action. There are many things one doesn’t understand and therefore, we ask them why don’t you just go ahead and take action; try to do something? You realize how little you know and you face your own failures and you simply can correct those failures and redo it again and at the second trial you realize another mistake or another thing you don’t like so you can redo it once again. So by constant improvement, or, should I say, the improvement based upon action, one can rise to the higher level of practice and knowledge”. – Fujio Cho
Read the rest of this entry »

1 Comment »

Can you MAKE a team Agile or more Agile?

Author: Susan Akers

Having just completed my ScrumMaster training I became aware that while Scrum is focussed on the Deliver Phase of Agile it is in fact, first and foremost about People! As Martin Kearns, our trainer, pointed out and this certainly resonated with me:
 This is evidenced by a recent story told to me by an Agile coach about a team they were working had just completed a challenging project in a very tight timeframe. The phenomenon about this team was that they had never worked together before, came from a wide variety of backgrounds and were working on a new platform, yet they were extremely productive from day 1! and delivered far beyond expectations; and their customers are delighted.
As we all know it can take months for some teams to become productive.

“You have to get the right people talking and doing! ..
The glue that holds people together is their emotional states and what commits people to the sprint is the emotions they feel.”

 

From your experiences, what are the factors that differentiate a ‘great’ team from the less-than great? Are there any common themes? What are the necessary ingredients?

2 Comments »

It is not ALWAYS the developer's fault …..

Author: Peter Sellers


…. that your software doesn’t work!

I’m not saying it’s never the developers fault. What I am saying is this – it is not just the developers who contribute to the success or failure of your software.

  • How can this be the case?
  • Who contributes to the success or failure of your software?
  • What can be done to improve the chances that your software will be a success?

Product/Business owners….Let’s discuss it!

This is the first of three discussions around the roles and responsibilities of the Product/Business Owner in the Agile software development life-cycle. In this first discussion I will look at the roles and responsibilities of the team members at the project level. In subsequent discussions I will look at their roles and responsibilities in the iteration and the story delivery life-cycle.

How can this be the case?During the project concept phase developers have no roles or responsibilities at all. It is not the developers who decide if your project is feasible. A technical lead/architect will be involved in the high-level design, but the decision on proceeding with the project does not rest on them.

The developers are responsible for engineering and writing the software that you ask for. How can it not be their fault?

The initiate phase sees the granulation of concept level work. Developers along with other team members participate in workshops at this phase. The developers play a role in helping to break down features into stories and refining the solution design among other things. Their role in these workshops is the same as every other team member present – to refine the concept. Developers may carry out technical ‘spikes’ around technical risks to help determine estimates and time frames, but for the most part they are merely members of a team identifying, prioritizing, estimating and planning at this stage.

Development is carried out by developers at the develop phase of the project. No prizes for getting that one right. Is this when it becomes their fault? Well, once again they are not the only members of the team involved in this phase. They are part of a team charged with building functionality that adds business value, and they need support from other team members to do this. The whole team should be involved in planning sessions, stand-ups, retrospectives and showcases during short iterative periods of development.

Developers play a large role in engineering functionality at this stage. It is there responsibility to develop code that meets acceptance criteria established by the whole team. This same code is tested manually by test analysts and demonstrated to you before being considered complete. That means everyone in the team has agreed what the developer should build, it has been tested and has been accepted by yourself.

Development is not carried out in isolation, the whole team is responsible for ensuring its quality, not just the developers.

Finally there is the deploy phase. Here the developers have a role to play in handover to the production support team. They will also be involved during creation of the back out strategy, data recovery and stress testing.

The developers role at this phase is largely supportive. Once more, this phase relies on team efforts – not just the developers.

Who contributes to the success or failure of your software?

If the developers are not the only ones responsible, then who else is? Who else contributes to the success or failure of your software?Typically the BA (Business Analyst), SME (Subject Matter Expert) and a technical lead/architect will take part in workshops during the concept phase of your project. These team members are responsible for formulating the desired outcomes, identifying features as well as preparing some high-level design and estimates. Their role is to determine if the initiative is worth doing.

As well as the BA, SME and a technical lead/architect, the developers and test analysts will all be involved at the project initiation phase. Every one of these team members has a role to play in adding detail to and refining the conceptual phase outcomes. Each team member is responsible for utilizing their unique expertise to elicit stories, prioritize, design, estimate and plan during a series of workshops.

So who else contributes during the develop phase? Strange as it may sound the BA, SME, test analysts and a technical lead/architect have just as much to contribute during this phase as previous phases.

Infrastructure also become involved at this phase – as a focus starts to be put on deployment and production support.

Each team member attends planning and story elaboration sessions, stand-ups, retrospectives and showcases. Each has a responsibility to contribute their skills, even during the feature development cycle (which we will discuss further at a later date).

Test Analysts have a responsibility to test features as they are developed. You are responsible for agreeing that the acceptance criteria is met during a demonstration/showcase. You have a role to play in the quality of your software during the development phase.

During the deploy phase the SME, Test Analysts and production support teams all have roles to play. The main objectives of this phase are to move to a production environment, whilst ensuring a good handover to the production support team.

Handover to the production support team occurs with support from developers. Final user acceptance testing occurs at this time. Data Recovery, stress and load testing will be carried out by Test Analysts during this phase.

What can be done to improve the chances that your software will be a success?

So if there are so many people contributing to the softwares success, what can be done to improve the chances of success?

Use the project concept phase to determine if it makes business sense. Ensure the business benefits exist to make the project worthwhile. Establishing SMART (Specific, Measurable, Attainable, Relevant, Time-Bound) goals and completing value sliders at this stage will enable you to measure project success. Tying features to business benefits helps prioritize implementation. Ensure diligent risk analysis is carried out too.

Even at this conceptual stage there is a serious chance of impacting project success. Don’t take it for granted. Use it to your advantage.

At the initiate phase of the project involve the whole development team. Ensure identified features are broken down in to stories. Map the stories to the business processes to ensure nothing is missing. At this stage prioritize the stories based on MOSCOW (Must have, Should have, Could have, Won’t have). Prioritize on business value not effort or complexity. Also, carry out risk analysis on the stories and plan to deal with high risk ones in early iterations.

During the initiate phase prepare the test strategy – the what, when and how of testing. Estimation plays a big role at this phase. Estimation workshops carried out now help you produce effective plans. The estimates, plans, risk analysis and prioritizing all have an impact on the projects chances of success. Utilizing the teams combined skills improves your chances of success – even before development has begun.

At the development phase, ensure developers use ATDD (Acceptance Test Driven Development)/TDD (Test Driven Development) methodologies. The ATDD/TDD methodologies combined lead to leaner code, written when needed, that meets acceptance criteria. Developers doing this, will improve your chances of success.

Around the development cycle in this phase ensure iteration planning and story elaboration involving the whole team take place. Create a shared level of understanding about goals and stories throughout the whole team. Don’t neglect the retrospective, and the chance it provides to review, action and implement changes to help the team succeed.

The aim of the develop phase is to produce working software at the end of each short iteration. Hold a showcase, highlighting the new features. The showcase also enables your team to get early feedback on developed features prior to release.

The deploy phase needs to be started well in advance to be successful. Engage the production support team early. This will help to make the handover smoother. Carry out data recovery and stress testing during the deliver phase, providing the team time to identify problems and fix any issues.

As this phase often involves tasks that take a lot of time, plan to do as many of the tasks as possible during the deliver phase. Addressing these tasks early offers the best chance of a successful deploy phase.

Build Quality In

As we have seen quality is the responsibility of every team member in an agile team, not just the developers. Every team member has a role to play in building quality in.

Are you ready yet to admit…it’s not ALWAYS the developers fault?

Leave a comment »