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 »

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 »

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 »

Lessons learned on my Agile journey

Author: Colin McCririck

On a recent walk by the story walls of nearby teams I noticed some small innovations which led me to say “have you seen …..” at our management stand-up. I’ve now found little things on one team’s wall have permeated across teams to their walls including:

  • Slow moving card sticker
  • Repeating card sticker (for tasks or other items that repeat in multiple iterations)
  • An ‘away sick’ and ‘on holidays’ area on the wall to put people’s avatars, so that these things are visible to all visitors and the team – a big advantage of this is – the reduction in email (one of my pet hates is using email for all communication).

Some of the above might seem trivial but small improvements often make big changes over time. They also made me think and reflect on how I have viewed Agile:

  1. Agile maturity comes with many small steps
  2. It’s important to encourage teams to make these steps themselves
  3. Copying between teams is encouraged and is not cheating (as schools might have taught!)
  4. Having a critical mass of Agile teams propels maturity further due to the copying synergy (i.e. shared learning).

I thought Agile was much easier in small teams and organisations but am now convinced large organisations have greater opportunity to push boundaries further in the Agile journey. However, it does require patience and commitment to long term gain through small improvements and a culture that allows and encourages it.

Leave a comment »

Agile's Secret Sauce – Part 3

Authors: Tracey Kay and Julian Coldrey

As project leads, we bring a certain perspective to how we have achieved the team culture described in Part 2 of this series.

So here are some things we did as a project leadership team that seemed to get a good result:

  • We picked the right people. It’s not about assembling the best, most high achieving collection of people. It’s about team fit and picking a group of people who work well together and, as a team, EXCEL.
  • We let the team self-select almost everything. Nothing says empowerment like the ability to choose how you work, what you work on, and who you work with. By enabling our teams to self-select and organise around our goals, they took on the choices as their own and were much more inclined to make them work (or even better, change them when it was obvious they weren’t working!)
  • We eliminated Leads to create accountability. It may seem counterintuitive to drive accountability by eliminating leads in an Agile team, but past experience showed us time and time again that creating leads for each skill set (“Dev leads,” “Test leads,” “BA leads”) caused an immediate diminishing of accountability with the rest of the team. We felt that if someone was given the “lead” role that it flew in the face of the culture of shared accountability we wanted to generate, so no leads became the order of the day.
  • We chose a specific leadership style. Leadership is always important, but in an Agile environment where empowerment and self-direction are critical to success, choosing the right leadership style is paramount. We decided to provide leadership that focused on the vision and purpose of the team, but which was not directive in terms of how to achieve these goals. In other words, our mantra was always “this is what we need to do, now let’s figure out how to do it as a team.” This really empowered the team, got everyone thinking, and ultimately helped create the sort of culture we were looking for.

We hope some of musings in this three part series about what makes up Agile’s secret sauce has resonated with your experiences of building high performing Agile teams. If we could take one thing away from this project experience, it’s that we’ve never regretted any investment we made into building a healthy team culture, as it has consistently been repaid in the form of a fantastic, high performing team who have fun!

Feel free to send us your Agile recipes for success too or direct us to other good blogs/articles.

Leave a comment »