Go for small

One of the primary advantages of adopting Agile is that it allows you to change course quickly in order to react to changing market dynamics. This benefit can only be realized if you go for small. This is especially important if you are just starting out on adopting Agile / Scrum for your organization. Let's talk about benefits of going for small one by one concentrating on People, Process and Product.

People

Small Teams:

Value small team sizes over large team sizes. A small team involves less co-ordination between people. Research indicates a 4-7 person team size is ideal for Agile. Here is a link to Jeff Sutherland's article where he talks about keeping team size under 7.

Process

Short Sprint Cycle:

One of the principles behind the Agile manifesto states that Agile implementations should go for iteration sizes from a couple of weeks to a couple of months with more preference to shorter time scale. 

Shorter sprint cycles gives more opportunities for the product owner to prioritize what the team is actively working on. This helps deliver the primary advantage of Agile - adapt to changing customer needs.

Short Release Cycles:

With shorter release cycles, the team can deliver value to the customer quickly; allowing for better feedback loops. This enables the team to further add value to the product where it is most needed. 

Shorter release cycles allow for the Product Owner to quickly adapt the product to customer needs by doing feature driven releases. Shorter release cycles also give confidence to customers that the product is actively being worked on, and their concerns will be addressed soon.

I recently worked on a project where there was a crisis of confidence in the customers. The product was not doing well at all when we took over. With shorter sprint and release cycles, my team and I were able to turn the product sentiment in a matter of a few quick releases. 

Product

Small Curated Product Backlog Size:

I encourage product owners to curate / groom only small batches of the product backlog. In my experience, having the top 10-15 items in the product backlog prioritized correctly is enough for the Scrum process to work. 

Teams don't necessarily need clarity on what they are going to work on several years from today, they just need to know what is coming up next. This helps provide transparency - giving the team a good sense of what the minimum viable product looks like. When the team has this view, it can write code that can be refactored to suit the product needs better.

Small sprint backlog size:

If you are doing short sprint cycles, a small sprint backlog follows automatically. Instead of pushing the team to do more in each sprint, it is important to for Scrum Masters to let the team find a sustainable pace. This allows for a valuable velocity estimate, which makes the team predictable. 

Small Stories:

I am a big fan of breaking big problems down into smaller / simpler chunks. I have talked about Valuing Simplicity in another post. Here are some of the advantages of small story sizes:

1. Small and simple stories help the team understand the problem clearly. 
2. Small stories help the product owner and the team solve the correct problem. 
3. Small stories allow for producing working software at the end of the sprint. 
4. Small stories can help produce excellent looking burn down charts. If your team's burn down is a 'falling off a cliff', most probable cause is that the stories are too big.

Code - Small Classes / Small Methods:

All my experience as a Software Developer points to small classes and small methods being more maintainable over large ones. 

I have personally written code and worked on systems that adopt design patterns like Factory, Decorator, Strategy and Observer / Listener among others. All these patterns allow the code to be extendable and maintainable, while not being overly complicated. 

If you have a good design, it can allow you to write code in small classes and small methods. This usually makes the code easy to read and understand - thus making it more maintainable.

Small Test suites:

I have worked on a couple of projects where we had a large battery of small tests. Irrespective of whether they were manual or automated, small tests allowed the teams to pick and choose which tests to run for a particular test cycle. The team could pick and choose the right set of tests for 'Sprint Sanity' depending on the area of the code that was modified. 

Overall, I strongly recommend thinking about how to make things small for a good Agile implementation.

Rate this post!

☆

☆

☆

☆

☆