Top 10 Questions To Ask Before Setting Up An Agile Team

1. Setting Up An Agile Team

Firstly, although setting up an agile team may seem to be "easy," based on our experience, the results can vary greatly. What mistakes do people make? What can we do to increase the chances of our success?

In general people like a degree of certainty and stability that is inherently at odds with the flexible changing nature of an agile SDLC project. There are many mistakes that can be made, in no particular order, some of them are:

• Gold Plating – a lot of highly technical developers tend to want to think of all the possible ways a piece of code could be used and make it as powerful and beautiful and wonderful as possible, but if it’s not relevant to the specific user story or valued by the customer then it’s unnecessary. I remember a project where an engineer spent 3 months building the world’s best logging framework…! To increase changes of success, have frequent team meetings where the team can get consensus on what ‘good enough’ means.
• Only thinking of agile for developers – most projects consist of a cross-functional team involving developers, testers, business analysts, user interface designers, graphic designers, information architects, etc. There is often a tension between non-development disciplines that still think waterfall (e.g. designers who want to know every possible way something can be used to design the most elegant interface) and the technical team that wants to get the first iteration out quickly. To increase chances of success, work out an explicit understanding of how much of the non-development upfront design needs to be "concepted" out up-front and make sure that everyone knows that it’s not set in stone and will be refactored.
• Communicating carefully with customers / end users. One challenge with agile is that you cannot necessarily guarantee that Feature X will be in version 2.X.X since after version 1.X.X you learn that Feature Y is much more important. Especially in situations where you don’t have a single customer, being very clear as to what’s actually planned vs. what’s just in the product backlog is important to avoid mis-set expectations, a stressed team and a frustrated set of customers.
• Scope Creep – like home remodeling there is always the danger of the “might as well” functionality. Since we’re developing module X for user story X we “might as well” also add feature Y since it’ll be quicker to do it now. Unfortunately feature Y adds complexity and reduces time for the other user stories that the customer does want. To increase the chances for success, make sure that the project management and team have open communication and the solution architects are having frequent design sessions (on whiteboards) and informal chats with developers so that they have a handle on the day to day technical decisions.
• User stories not being true user-facing, testable, business-driven requirements (e.g. develop data-access layer is NOT a story). Stories should be architecturally ‘vertical’ not ‘horizontal’.

2. What determines which methodology is best for a given team or project?

Most teams that we have worked with, have generally taken aspects of several agile methodologies and blended them into something that is appropriate for the customer, team size, level of maturity of the system (new build vs. maintenance) and communication available with the end users. However some suggestions would be:

• XP vs. Scrum
  1. Scrum and XP are in reality mostly complimentary with XP focusing on the engineering (continuous integration, test-driven development, etc.) and Scrum focusing more on the management side (burn-down, fixed scope for sprints/iterations, etc.). So you tend to choose elements of Scrum and XP together for the specific project (e.g. don’t use pair programming, but use continuous integration).
  2. The length of the sprint/iteration and how the work in the iteration gets scheduled / sequenced would differ between XP and Scrum and would depend in many regards on how frequently the customer can take part on accepting the result of the iteration and also how easy the team can communicate. In general the choice of iteration length, how user stories within a sprint get sequenced and whether the scope of the iteration can change would be largely driven by what makes sense for the customer/team and their comfort level with the choice.
  3. Scrum is a more defined methodology than XP, so if you have a less experienced team, starting with pure Scrum and then adding the appropriate XP engineering practices would be a good approach. Starting with raw XP is harder because it requires more invention at the start to put all its principles together.
• Kanban vs. Scrum
  1. Kanban is newer and doesn’t have the rigidity of Scrum/XP in terms of fixed-iterations, it has its background in Lean and therefore is more concerned about WIP and the flow of tasks through lifecycle. So it’s a good choice where having defined iterations doesn’t make sense (e.g. in a support/maintenance role). However similar to what was mentioned for Scrum, once you have the Basic Kanban methodology and task flow visualizations in place, adding the XP engineering practices makes sense.
  2. If you have a project where the scope is changing more unpredictably that can be factored into X-week iterations, then adopting a Kanban-style methodology would make sense.
  3. If you have a less experienced team Scrum has the advantage of being relatively easy to define and setup in one go, whereas Kanban is more subtle and needs more time to get up and running
  4. If you are in an existing waterfall environment, switching to Scrum or pure-XP would be a shock change, whereas you could adapt to Kanban more gradually. You could also add in the XP practices in concert with Kanban methodology.

3. How do I make it easier for new team members to adjust to "our" agile approach?

I as a developer may work on one project with one team and then be assigned to another project with another team in the future. If I've been using a particular methodology (Scrum, XP, Kanban, etc.) how easily will I be able to get up to speed on another or the other methodologies as time goes by? What can I as a project manager or director of development do to ease such transitions?

• In any project team there will be the formal practices (e.g. Scrum) and then the information conventions that develop over time that are team specific regardless of the methodology name. The key will be to help an incoming developer understand both the formal methodology and the internal conventions so that they feel part of the team and understand how the team operates.
• That being said, project managers can help by encouraging the team members to explain ‘why’ a particular process is used and now just ‘what’ the process is. Also encouraging the team (and themselves) to be open to changing the processes. If a developer from an XP team comes to a Scrum team and challenges why they are not doing pair programming (for example), rather than the usual (‘that’s not how scrum works”, or “that’s now what we do on this team”), having the open-mind to explain why they’ve not followed that practice and also even considering if it could be useful (e.g. on high-risk parts of the system have pair programming).

4. Take the ego out of "best practices"

People always talk about using "best practices" but sometimes that's little more than an ego statement. How can I be sure we truly are using best practices? How as a manager can I best enforce/encourage/ensure that?

• There is a danger that following ‘best practices’ simply means not actually thinking about what is appropriate. We have seen teams use all these tools and frameworks because they were a best practice for 100-person team but overkill for a 5-person one.
• One way to make sure they’re using best practices is to rotate people through projects (if possible) so that they can see how other teams operate. Also encouraging team members to have time each day to research new ideas online and present back to the team (e.g. brown-bag lunches). At one company we worked with (that adopted agile), we had a new manager come in and present XP to the group, it completely changed how we did business.
• Also encourage team members to throw out what works and try new things (e.g. just because Jenkins works, no reason to not try out Travis or TeamCity, same thing with Subversion/Git).
• As a manager, scheduling a weekly brown-bag would help and also asking developers “why” three-times to make sure they’re not just choosing the safe answer (e.g. why don’t we use test-driven development, why don’t we use behavior-driven development, why don’t use-cases have a role in agile?)

5. Select the "right" tool for your project

Then there are tool choices. What mistakes might we make here? What can we do to ensure we're getting the right tools for the right reasons that are right for the job? As our needs evolve, how can we be sure our acquisition of tools is on track?

Here are some of the common mistakes we hear from customers when they have chosen a tool:

• Choosing a tool for just one part of the team. For example, choosing a bug-tracker, source code control tool and build server works well for the developers, but what about the UI designers and testers. Do they have to just ‘live’ with the choice.
• Choosing the most complex and powerful tool just because we might need it one day. Data migration is a pain if we have to switch, but going with the ‘good enough for now plus what we know we’ll need next month’ is usually better. I remember a team fighting with Rational Rose and ClearCase for weeks before we even got started.
• Not considering exit-strategy. Even though we don’t want to have the most complex and powerful tool necessarily upfront, at least making sure that whatever tool we have now has at least the ability to export the data into an open format and/or has APIs for accessing the data.
• Listening to the marketing folks, always take a real trial of the tool, e.g. a 30-90-day demo using real project data to see how it works for the team for real, not just a 15-day demo with sample data and a bunch of executives looking at pretty reports and dashboards.

6. Consider all the pieces of the puzzle when choosing a tool

While we're talking about tools, for teams with "little" hands-on experience, how likely is it that we're thinking in terms of ALM and not just pieces of the puzzle? (I realize the reality varies from team-to-team but how will our experience and outcomes vary if we're thinking piecemeal or we want to do ALM right?)

1. For example, an ALM system like SpiraTeam has many features and capabilities (vs. just using Jira and Github) that won’t be needed upfront and so there is the temptation to just get the basic tools and glue them together, however you can quickly end up building your own ALM suite from scratch and having to manage all the integration.
2. A good idea is to choose tool(s) that are relatively quick to setup and don’t require the entire suite to be used for the other modules to be useful. So if you choose an ALM suite that needs all the requirements, stories, test cases, defects, tasks, source code, build management to be done in that tool then it’s probably not a good choice. Look for tools that offer more than one feature but allow you to just use one feature at the start so that you can deliver value from day one.
3. Look for tools that don’t tie you to a specific methodology. If you have a tool that is 100% scrum only, you will not be able to add elements of XP or Kanban so easily (for example).

7. Should we enlist a third-party consultant?

Are we wise to get help from third-party consultants, vendor consultants/trainers? If so, given limited budgets (everybody claims to have them) how can we be sure we're making wise investments that truly pay off?

1. It depends on the skills/knowledge of the team, how quickly you want to get up to speed and how much budget you have!! So it’s a really a situation that depends on the project. Certainly in some cases it’s a very good idea.
2. To get the most value, when a team is assembled, look at the skills you have and the experiences that are weaker, look at the tools you plan on using and see if you have source the training organically within the team, then for those items that are critical to delivery and don’t exist on the team, consider hiring an external consultant/trainer. If you are using a tool that no-body on the team has used much before and you are worried about deadlines, you could hire the vendor’s trainers.
3. Some tools require a lot of customizations and add-ons to be useful, so beware, they may be promoted by consultants and trainers as a way to generate need for their services. Other tools may be more turnkey, and therefore need less assistance from third-party consultants.

8. How do we avoid "just enough knowledge to be dangerous"?

Sometimes there a danger that as a group or certain people within a group know just enough to be dangerous? If so what are the dangers?

• The more vocal members of the group with some experience overrule the other members of the team who may be more experienced with other aspects (the platform, technology, industry, etc.) and as a result key decisions get made for the wrong reasons. For example on a pharmaceutical project where you have lots of regulatory requirements, you can use agile, but it requires some modifications and additional documentation, which a team that’s done agile before might not realize.
• The group never improves, one of the key aspects of Lean/Kanban is to continually reinvent and improve, if the team thinks they know enough then they may stagnate and not improve.
• The team incorrectly interprets the project scale. For example if the team has experience doing agile with a 5-person co-located team they will underestimate the complexity of a 50-person distributed team and not adjust the methodology and tool choice accordingly. For example using a more defined prioritization (XP style) for tasks/stories might be better when half of the team is in a different timezone and it’s hard to know what tasks the other half of the team has already chosen.
• The team incorrectly interprets the project technical risk. One danger with agile is that the team chooses the same architecture as the last project and gets to work on iteration/sprint 1 delivering the user stories because that’s what they’re supposed to do. However the project has much higher-performance requirements and what should be required is a proof of concept / spike solution iteration upfront to mitigate/flush-out any technical risks.

9. Some other gotchas when adopting Agile methodologies for the first time

1. The power of testing, aspects such as unit testing, automated testing and load testing, items which are critical for agile since you don’t have the time to manually retest the entire system each iteration, also the techniques for knowing where to focus testing resources.
2. How to ensure design elegance, one challenge with Agile is to avoid the ‘camel’ and make when the user interface is refactored in iterations 1-5 on a project, the end result is always usable. How to align the UI discipline with agile
3. Ways to mitigate the communication challenges for teams that are geographically and temporally dispersed (over timezones).
4. How to re-educate experienced developers and managers that come from a waterfall background. This is usually harder than a completely inexperienced team in many ways.

10. Some final considerations

We hope this list was helpful. A couple of key things we recommend you always consider when setting up and agile project:

• How does the experience of setting up an agile project vary by the type of project and some recommended best practices:
  • Brand new system
  • Enhancing an established system
  • Support and maintenance of an existing system
  • Highly regulated environment (pharmaceutical, insurance, healthcare, etc.)
• How to build quality into an agile project from day one.