In the last post, I talked about how to be more Agile in your customer interaction and requirements gathering when the business is strictly Waterfall. I’d like to continue along the theme where business isn’t as Agile in its execution of projects as agilely proper and how that business deals with the ‘team’ concept.
When I worked in the defense industry, teams were defined around specific functionality. I was a project manager around torpedoes, someone else was missiles, another navigation, and so on. We worked in a loose ‘feature team’ configuration. When you looked a little deeper into our team structure you’d quickly find we were actually grouped specialists, working independently from one another. One or two people would specialize in torpedo interfaces, another person would be pre-launch display, another post-launch display. Specialization was the core of our development efforts and it worked well because we also had many layers of both project and line management to oversee everything going on. If anyone even vaguely looked like they were off track, there were several people monitoring who could set them straight. The team was not allowed to deviate from the implementation plan, deviate from the customer approved designs, or innovate on their own. Control was absolute and the projects tended to be successful, you really can’t lose on a cost-plus contract. Our company, like many companies, talked fluently about teams and teamwork.
Teamwork is a value that almost every company claims. In Agile, there are several principles promoting the idea that the team is central. The principles include people other than the development team as part of the ‘Agile team’. These principles are:
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development Team is face-to-face conversation.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- The best architectures, requirements, and designs emerge from self-organizing Teams.
The best way forward to building the idea of team in product development is through early and constant engagement of the developers, product manager, business stakeholders, and customers. We humans have a tendency to claim credit as individuals for successes and attribute blame to others for failures. In the traditional project management model, the project manager is the person most likely to be hung out to dry if the project misses the project’s cost, schedule, and scope requirements. In the Agile model, we try to allocated responsibility to the larger team. Agile encourages participation of the larger team to accomplish great things. It’s important that the larger team understand and feel responsible toward achieving these great outcomes. This feeling of responsibility can occur with or without a project manager. The best Waterfall projects I was on made expectations clear to everyone from the developers all the way up through to the program office. Managers and workers alike knew what was expected of them.
In either a Waterfall or Agile environment, building a strong team is equally possible. The key to get people feeling responsible for project outcomes is providing them with clear definitions of expected individual actions and outcomes. Creating a great team starts with getting those outside the development team, stakeholders, managers, program office, sales, marketing, and others, aligned with the team.
Stakeholders as team members
In Agile, we might start with a ‘Who Do’ table like the one shown below. In traditional project planning there is often a Stakeholder Management Plan or Stakeholder Involvement Matrix. Building the plan or ‘Who Do’ table will be much more meaningful if done with all the stakeholders and development teams together. Getting a verbal acknowledgement from stakeholders and development team members alike will greatly increase the likelihood of people following through and honoring their individual and team commitments.
Getting all your stakeholders and team members together in one room might be difficult if your project is huge. However, the rewards will be better understanding and commitments to the project by those who can influence the successful outcomes. If there are too many people then the Scrum Master or Agile Project Manager can get the larger group to break out into smaller working groups, each with a defined purpose. For example one group might represent the architectural steering committee and define what the company requires, what stakeholders need as far as information goes, and what the development team (or project team) needs from the architectural steering committee. The facilitator gets more than just a list of items but gets everyone to commit to delivering what they said they’d deliver.
The outcomes and ‘Who Do’ lists are drawn up for the entire project and placed on a wall in a very prominent location. This must be visible to all and not buried in a document in some obscure location.
For the Scrum Master or Agile Project Manager, the main obstacle will be the reluctance of the business to commit the time necessary for this meeting, whether part of an Inception Workshop or stand alone. The key argument for such a meeting is to remove project risk and increase chances of project success by clearly identifying actions and individual responsibilities throughout the organization.
In Agile, the Agile development team is usually defined as a team that not only cares about the work they collectively do but they care about the growth and well-being of each other. In a Command & Control environment, survival often rests with the individual watching out for themselves. My experiences in Command & Control environments was your individual performance was what mattered and the ‘team’ was secondary. Stopping to help someone was not uncommon but the usual action was to inform management that a person wasn’t up to the task. It became a management problem, not a team problem. The difference between being in a ‘group’ and being a member of a ‘team’ is the ability to sacrifice your time to help or guide others.
If the business is rooted in a Command & Control hierarchy, being told what to do is the norm. To achieve aspects of an Agile team mentality requires the group to not only adopt the project goals but for the group to lay down objectives and goals for themselves. One way to form a team from the group is by defining boundaries with the team and management. Within these boundaries, the team is self-reliant and self-managing. The team can define their own behavior using a Team Charter declaration. A Team Charter is a common artifact in Waterfall and Command & Control environments and can be used to identify many of the Agile behaviors in a familiar form. I’ve found that the act of developing the charter with the team is more important than the resulting document. The charter is placed prominently on the team’s Sprint Board.
Management concerns will rest along the lines of giving up some control. These managers are being held responsible by those above so it is a leap of faith to grant the team any autonomy. For the Scrum Master or Agile Project Manager, it will be important to ensure that there exists some checks and balances so the managers can feel comfortable. These concerns will most likely initially focus on ‘output’ (not outcomes) of the individual sprints. The Scrum Master can help the team report their sprint progress in terms managers need to hear. In the past, I had focused on reporting user stories estimates which began very high as a reflection of the team’s uncertainty. Over time, the size of stories fell which was directly related to the team’s efforts in backlog grooming. This demonstrated real progress, the team better understanding the work before them, something that was both visible and valuable to the business.
Example Agile Team Charter
The act of creating the team charter is more valuable than the resulting document in my opinion. The team debates each item and may spend a little time on the exact wording but in the end they agreed to the concepts and behavioral traits. Give it a try.
- The Team will decompose tasks so they can be done in less than one day – based on knowledge at hand.
- The Team will display a Sprint Backlog burndown chart prominently to track progress.
- The team will constantly review the content of the Sprint Backlog to ensure it is complete (no missing tasks) and that all tasks planned and being undertaken are necessary for the successful completion of the Goals.
- The team will alert the Product Owner immediately should it become apparent a committed User Story or Goal cannot be achieved.
- Every Team member has a responsibility to speak up if they feel a Team member is working on a task that is of a lower priority to other tasks not yet started. Every Team member is responsible for the progress of the team, not just of their own progress
- The Team will fix any bug they’ve introduced during the Sprint unless the Product Owner approves not fixing the bug.
- The Team will create automated tests (unit, integration, functional, acceptance) even if the result is reduced functionality during the Sprint.
- To move a task from “to do” to “in progress”, the task is broken down to no more than can be done in the remaining time before the next Daily Scrum meeting – based on knowledge at hand.
- When a task moves from “to do” to “in progress”, the Team member commits to working that task to completion.
- The Team will integrate working code often, no less frequently than every 24 hours.
- The Team will not tolerate broken builds. If the daily build is broken the team will refocus to fix the build immediately.
- The Team will not check-in new code if the daily build is broken
- Before a coding task moves to “to verify”, the following items must have occurred (part of the Team’s definition of “Done” for a functional task):
- Code and Unit/Integration Tests are peer reviewed using pair code walk-through technique
- Code unit/integration testing have been automated and added to the daily build
- Developer build made and integration testing completed successfully
- The assessment of impact (for the change or new feature) is documented on the Jira form with any recommended regression tests identified.
- To Move Task From “to verify” to “completed” requires (part of the Team’s definition of “Done” for a functional task)::
- Daily build with changes has no errors (if errors, source backed out and task returns to “in progress”)
- Product Owner has been informed that a new daily build is available and what new/modified functionality is completed
- Automatic unit/integration tests run during the daily build have 0 errors and warnings
- If applicable, acceptance tests run successfully for completed User Story (or portions run successfully for partially completed User Story)
- Jira used for code delivery has passed verification and identified regression tests have been run.
- All new defects are entered as Jiras. Principle development is complete with issues treated as rework via Jira.
- Team member who developed code and plus one or more team members have run the Jira verification and recommended regression tests on the daily build
- The Team will work at a sustainable pace; a pace which can be maintained for 12 months.
- Every Team Member will actively seek out and eliminate waste in Software Development