Agile Practices – What Comes Next?

Agile practices are arguably the most implemented management frameworks in software companies.

However, many still struggle to grow them into an adaptable and dynamic framework that allows for continuous improvement in their company.

It can be tough finding the right balance between tools and systems for your team.

Though when you do find a balance, company wide growth comes more naturally.

General UI is one agency that have advanced their agile practices into a state CEO Jason Thane calls ‘post-agile’, enabling them to consistently produce great quality software for thousands of customers per year.

Our CEO and co-founder John-Daniel Trask interviewed Jason and their Director Of Development Kevin Klinemeier to find out how they moved their team into what they describe as a post-agile state.

Here are some of the key takeaways from the interview:

See ‘Agile’ As A Noun Rather Than An Adjective

What does he mean by this?

Jason explains that he hasn’t thrown agile practices out with the bathwater altogether, although he’s made some key distinctions.

He goes on to explain that he often sees (in his clients in-particular) an almost ritualistic following of agile practices. General UI however, tend to see agile as a tool, rather than a set of rules to be followed without flexibility.

Within that, every tool is seen as an optimisation – appropriate for certain situations but wildly inappropriate for others. If you can understand why you’ve implemented your tools and how exactly to use them to their maximum benefit, you can start to see results much quicker, and therefore assess what the next step is.

Eliminate ‘Towers Of Knowledge’ In Current Agile Practices

For those of you with consultancies, you’ll know a project can be slowed to a halt because of sickness or a project leader being otherwise tied up. To get around this,  General UI see a lot of value in pair programming (or peer programming as it’s sometimes referred to.)

As Director of Development, Kevin makes sure that at least two people know what’s happening at all times, which drives their practice around rotating pairs. So every day, developers get to work with different people sharing not only product knowledge but engineering practices.

In their previous agile practices, they found that communication didn’t necessarily flow in their company.

With pair programming however, ideas spread quickly, almost eliminating the need for 30 minute meetings on new practices. Seeing changes in real code rather than in theory allows everyone to get the work done a lot quicker. And it quickly becomes apparent what is working and what isn’t.

Revisit Your Code Review Practice

After introducing a pair programming experiment into their team, they realised that their current code review system was slightly flawed in the fact that every line of code was looked over by four or five people.

Kevin admits it made him a better coder, but it took a long time to get things done. He also admits that not all the feedback was useful either – everyone offered input to a code review which often led to unnecessary changes – in turn chewing up valuable time.

Once pair programming was initiated, they noticed when it came to the code review, feedback was mostly positive and there wasn’t much to change.

Jason also highlights that he believes the value of this type of working together has benefits more fundamental than that:

Jason makes the point that software has a complex integration surface with the world around it, as software itself is an active communication. When the software development is disconnected from the world around it (as in a lack of communication between people that build it) software tends to grow ‘in directions that it probably shouldn’t.’

The benefits for General UI have been ‘tremendous’. In these benefits, he includes high-bandwidth, and high-integrity communication which, in turn, leads to increased trust within the team.

Remaining Transparent On Pair Programming With Clients

CEO Jason Thane remains transparent with his clients when it comes to why they chose pair programming. After all, it’s the client’s time and money. He understands their methods can be called into question, and he makes it a priority to help the clients understand his reasoning.

Jason explains this isn’t necessarily a bad comparison. There are essentially two roles in General UI’s pair initiative:

The Driver – The person with the keys looking after formatting

The Navigator – Thinks about design , architecture and user experience

Jason argues that it takes years for a single coder to be able to think both at a higher level (UX, design, etc) and at a lower level (code). He sees great value in the ‘intellectual rest’ that pair programming offers, mentioning they are both key to a better quality end product. This makes selling pair programming to clients much easier.

Risk Reduction For Project Management

General UI have seen an inefficiency in how their errors were originally being managed. Their pre-agile process was seeing a long bug tail that was tough to fix. However, with two people working in a pair, they noticed the bug tail was really short as they were being fixed in-line.

With an error and crash reporting software like Raygun built in, they are able to eliminate wasteful processes that sees many minor bugs sitting in repositories waiting to be compiled, built and deployed.

When Sprints Aren’t Necessarily An Optimisation

Because General UI are often managing 10 clients at a time, they realise sprints aren’t necessarily the best way to allocate resources.

If you have one product team or are a large organisation however, they work really well. They also mention that if you have an external cadence to move past, like a long product release cycle, it could be best to use sprints.

Jason highlights in order to make your current agile practices more efficient, it could be worth looking at how resources are currently allocated and if there could be any improvements.

Pair Programming From A Management Perspective

When two people don’t get along, it quickly becomes obvious. But what General UI noticed was that when communication was open, it lead to the team being able to disagree usefully. So solutions weren’t “my answer” vs. “your answer”, it was more collaborative, landing somewhere in the middle with a third (often better) team approach.

Kevin is clear there’s no magic bullet when it comes to how to allocate resources effectively – it will be trial and error.

One thing that shifted the needle was using a tool like Jira, which allocates resources internally. But if you have to, use sticky notes and markers. As long as it’s flexible.

Jason’s secret sauce is to assign projects to be completed, rather than to assign people to projects. They let people vote with their feet and work on projects they are most interested in (not necessarily what they are best at). This has the added benefit of increasing the spread of knowledge within the company, and ultimately increasing trust levels within the team.

Jason and Kevin also noticed a 5 week grace period where everyone found peer programming quite frustrating. After that, it was really positive.

“…the measurable and pragmatic advantages are tremendous as well…showing the economic advantage of pair-programing. And it extends from shared engineered practices, shorter ramp up time, in-line bug fix and defect fix. And, overall, product quality leading to reduced need for successive fixed releases.”

So from an economic perspective, the angle Jason recommends is that it’s about sustainability. Due to the nature of development teams having high turnover, it could be likely that projects die as the lead developer leaves. But in the case of pair programming you have an insurance policy in the shared knowledge.

Regular Retros Manage Team Expectations And Bring Issues To The Surface

To keep everything open and allow continuous communication both Kevin and Jason emphasise the importance of getting the team to reflect regularly, both on the tasks they have completed, what went well, what didn’t go so well and what they are working on.

This allows any issues to bubble to the surface so they can be smoothed out and encourage a constructive cooperation. General UI recognised that the growth of their company relied on their agile practices being founded on their team members first:

_Conclusion _

Both Kevin and Jason of General UI agree that being open and allowing communication has being crucial to their success in being ‘post agile’. They are on the path of ‘continuous improvement’ rather than following a rigid set of agile rules. However, they certainly don’t advocate a silver bullet approach, and encourage companies to continuously assess their current practices for improvement.

I hope you’ve learned a little about a working example of what can be described as a post-agile state, and has perhaps inspired you to re-visit your current agile practices to see where improvements can be made.

You can view the full webinar here.