Anatomy of an Agile Team
Observing a Waterfall Team and an Agile Team can tell you a lot about how the teams function. There are two key indications that a team is Agile.
whiteboards, sticky notes, diagrams, and work boards
First: Agile teams are noisy! They talk, debate, and share ideas. There is a high level of communication and an obvious culture of collaboration. Waterfall teams are meticulously careful with one another; they speak one at a time and are mindful of always remaining respectful.
The second most obvious difference is the amount of physical information that tends to surround Agile teams. You will often see whiteboards, sticky notes, diagrams, and work boards – all constantly shifting and changing as workflow progresses.
Waterfall teams work from documents. The Agile team is more like a social body than a group of individuals. There is a commonly-held belief that technical teams primarily spend their time writing code; when the reality is a good part of development comes from thinking, talking, and socializing ideas.
Individuals and Interactions over processes and tools
This means different team members working on the project talk to one another; creating a culture of collaboration throughout the life-cycle of the project instead of working in separate areas with separate general understandings of the project.
If processes and tools are seen as more valuable, the world people do must conform to those processes and tools. Conformity makes it hard to accommodate new ideas, new requirements, and new thinking. Agile, however, values people over process. This emphasis on individuals and teams puts the focus on people and their energy, skills, and ability to problem solve.
In Agile you’re still utilizing processes and tools, but they’re designed to be streamlined to directly support deliverables. The bigger a process or tool, the more you spend on maintaining it and the more you are required to keep going back to it. With people being the focus, the result is higher productivity. An agile environment is human-centered, collaborative and revolves around being readily adapted to new ideas and innovations.
Agile Tip
The Benefits of People over Processes:
Communication is clear and effective
Communication is quick and efficient
Teamwork builds cohesion
Teams can self-organize
Teams have opportunity to innovate
Teams are encouraged to customize their processes
Team members can take personal ownership of the project
Team members can have deeper job satisfaction
Working Software over comprehensive documentation
This doesn’t necessarily mean that documentation doesn’t have a time and a place. Agile simply prefers working software (left) over comprehensive documentation (right). It is a matter of priority and the value in documentation.
It’s important to remember that Agile states: “While there is value in the items on the right, we value the items on the left more.”
So essentially this is saying – use the appropriate level of documentation at the right time. This means asking yourself:
- How much time is spent on documentation?
- Who uses it?
- What is the minimum needed for the customers?
- How efficient is the sign-off process and how much time is spent waiting for approvals? What impact does this have on projects?
- Is there evidence of document duplication? Are different teams documenting the same things?
- If the documentation is simply for communication or development, how polished does it need to be?
Look for ways you can trim the fat, and reduce wasted time on documentation.
Have the team work together to create a quick sketch of the idea, or just chat with everyone and take notes rather than detailed documentation.
Play with some different ideas with your teammates to determine what works best for your office culture. Change these methods as often as necessary to find the right fit.
Customer Collaboration over contract negotiation
In the traditional Waterfall method, a vendor and a client would sign a contract to form a working relationship. In Waterfall, it is expected that the client would know exactly what is needed before the contract is signed, so any changes needed after work had begun ended up meaning extra charges, and delays to the launch date. All of these things take time, energy and effort and end up taking the focus away from delivering value.
In Agile we recognize that the three dimensions of any given project are time, scope and budget.
The first thing we do is determine which of the three is most important. We then work within these parameters with the client to determine the right set of requirements (or what we call ‘features’) that we can feasibly deliver within the time and budget available.
One of the key components to Agile is accepting that you can’t know everything that will come up.
Accept that changes will occur and have a plan in place for addressing changes.
Responding to Change over following a plan
The tradition of a project life-cycle is to plan and design every element of your project up front, as if things will never change. There are entire teams hired to map out the next several years. But the fact is, things always change.
Things may change for a variety of reasons. As work progresses the client and their stakeholders’ understanding of what the problems are and of what you are building changes. The business environment changes. Technology changes. Change is a reality, and a reality that your workflow process must reflect. There is nothing wrong with having a project plan, in fact it’s recommended that you do always have a basic plan. However, every plan must be malleable; there must be room to change it as needs arise otherwise your plan quickly becomes irrelevant.
Let’s take a look at two quick case studies of companies that have responded well to change: Twitter and Facebook.
Twitter is just 7 years old and when it started it was on Ruby on Rails because that’s what worked at the time. As the site gained popularity, it had to scale with the growth and today it’s on Scala.
Facebook has been through several technologies, and has had several face-lifts in its lifetime so far. The site wasn’t designed for every possibility that may occur on the internet because the creators had no idea what would happen with it. They iterated.
When you begin to form your plan, in order to ensure that the plan is malleable, keep these things in mind:
- Your plan can only be based on what you know right now
- Don’t get too attached to what you do right now and what you know right now
- Don’t expect 100% of your plan to get completed
- If you aren’t prepared to accommodate change, you will find the project life-cycle hard and sometimes impossible
- If you go in expecting change and have an adaptable team, the entire development process and project life-cycle will be that much better for it
And finally, the granddaddy of Change Masters: Google. Google has expanded and grown into an organization that prides itself on changing to accommodate the needs and demands of the people who use their services.
When Google was founded in 1998 by Larry Page and Sergey Brin, they wanted to make it easier to find high-quality information on the internet. That was the breadth of their vision. They hadn’t even thought of browsers (Chrome), phone operating systems (Jelly Bean), word processors (Drive), or tracking (Analytics). Those things came well after Google found success with their web search vision. It’s only taken 15 years to go from ‘simple’ web searches to the powerhouse we know that Google is today. Yet, how many enterprise projects are 3+ years in development and have never delivered working software or any value at all.
What’s Next?
Our team at ChromeMedia take every opportunity to improve our workflow processes. From web design and eCommerce right up to web accessibility and web applications, every new project is another chance to refine how we work, in order to deliver better value.
Want to see the fruits of our labor? Check out our portfolio!
Interested in working with us? Leave us a message and we’ll be happy to chat!
How does your team handle workflow? Let us know in the comments below!
[social-bio]