Think Big – Act Small: A New Way For Agile Teams?

INTRODUCTION

An Agile team is a cross-functional group of people that is self-contained to the point that the people in the group can deliver the product without needing to draw on skills outside the group. It’s almost easier to think of agile teams by virtue of what they are not. Agile teams aren’t simply a project team made up of various different people from different areas of the business. Teams aren’t solely developer resources. They aren’t a matrix team either.

Agile teams are dedicated groups of people who don’t move between products or teams just because there’s a demand in a different area of the business this week. Therefore they become a close-unite and trusted group of team members, finding a working rhythm for deliveries. They are a “whole team”. They don’t need anyone or anything else to get things done. This is particularly important when it comes to decision-making. They people who need to make the decisions are part of the team. Agile works for today’s projects.

Agile teams are composed of cross-functional, self-organized, highly effective groups of people. The three primary roles;

  • Scrum Master, who facilitates the team’s progress, helps plan iterations, gathers/analyzes the team’s metrics and ensures the team is working effectively together by removing roadblocks and encouraging collaboration/communication.
  • Product Owner who “owns” the feature(s). This person will prioritize work, define criteria for acceptance, approval of all delivered work, and participate in UAT/testing. This person collaborates with the business to protect the software being delivered is what will meet their needs.
  • Team Members represent a group of generalized specialists. This may include programmers, testers, developers, and architects, system administrators, UI/UX specialists, DBAs, etc. Team members are responsible for proposing, building, testing and delivering the best solution possible in each iteration. They design a solution and are allowed to make process changes or pushes back on requirements they think don’t make sense.

Business Capabilities

You should organize around products, or features, where you can.  Organize around subsystems where you have shared functionality. We call these business capabilities, collectively. Once you have the business capabilities understood, align the business capabilities with the technical architecture and ultimately the organizational architecture. The intersection and alignment of business, technical, and organizational architectures are where you form a complete cross-functional team.  A team of people that have everyone—and everything—necessary to produce a working, tested increment of their part of the product.

Because your business, technical, and organizational architectures are probably broken—you will have dependencies between these teams that you are going to have to manage. For now.

Dependencies

Over time, the job of the Transformation initiative is to break these dependencies because dependencies are evil and you need to break them.

Successful Agile Teams

When software teams successfully use agile delivery, they are able to release valuable, useable increments of work quickly. These increments may be small but, because they’re small, the team can complete the work in order of business value, the product owner can change their mind without bother the project, and the team may find smarter, more creative ways to meet the business need.  As the agile team works together they become consistent and expected in their delivery, making it easier to predict when key milestones will be met.  A self-organizing, collaborative team plans, develops, and make continuous developments which encourages quick and flexible response to change.  Being part of the agile culture requires a creative, flexible, and productive team player.

  • Working in a team incrementally and iteratively  

Scrum, like all of the agile processes, is both iterative and incremental. Since these words are used so frequently without definition, let’s define them. An iterative process is one that makes progress through successive refinement. A development team takes a first cut at a system, knowing it is incomplete or weak in some areas. The team then iteratively refines those areas until the product is satisfactory. With each iteration, the software is developed through the addition of greater detail.

For example, in a first iteration, a search screen might be coded to support only the simplest type of search. The second iteration might add additional search criteria. Finally, a third iteration may add error handling. A good analogy is sculpting. First, the sculptor selects a stone of the appropriate size. Next, the sculptor carves the general shape from the stone. At this point, one can perhaps distinguish the head and torso, and detect that the finished work will be of a human body rather than a bird. Next, the sculptor refines her work by adding detail. However, the carver is unlikely to look on any one area as complete until the entire work is complete.

  •  Change should be embraced

The client asks for change, team produce a change, and charge for it. In traditional methodology, teams were preventing change. For software development projects embracing the client’s changes early and updating before the deployment date can be very expressive.

Planning plays a crucial role in Agile. Though your end product is outstanding, how to deal with the market demands and conditions is critical part for embracing opportunity and change. In Agile methodology, the Stakeholder and the team prioritize and choose the highest-priority work to be completed during that iteration. Being flexible at an iteration stage, the client should not ask for the changes during this time. But your team can maintain the scope-of-work by working in 1 or 2 week intervals. If any changes needed then those changes can be pushed to the next iteration. There are some characteristics of new agile teams that includes limit to what team can accomplish during a fixed period of time. Things can go out of the scope, resources and costs can still change. Agile software development projects are exactly like that. You first think big to identify all components of the solution and the tasks that the team members need to work on as Product backlog products. These are initially at a really high level – may be as epics.

Conclusion

Think big, act small are 4 simple words with a great deep meaning which leads in creating new Agile teams. For an Agile team to become a successful robust team these are key principles for high performing Agile teams that can be preached and followed diligently.

Barghavi

Share