Almost all technology companies are using agile methods. But surprisingly enough, a number of executives do not understand what these methods mean in practice. This post shares a few elements to help you grasp the key concepts you need to understand in order to lead your technical teams efficiently.
Agile methods focus on short-term actions
Agile methods take into account uncertainty and thus avoid planning for long periods. Look at what the 5-year plans of Stalin did to the USSR and you will understand why it’s not a good idea to set your goals too far in the future.
Have a look at the picture below to understand the planning cycles.
|SCRUM process - By Lakeworks - Own work, GFDL, https://commons.wikimedia.org/w/index.php?curid=3526338|
As described in the above picture, you set the team goals for a Sprint. A sprint lasts for 2 weeks or up to 1 month. Never more than 1 month. The Sprint goals are set in a one-hour-long Sprint planning meeting, between the Dev Team Leader and the Product Owner. As the output of this meeting, you produce a work backlog update. The tasks for the Sprint are defined at a fine level of granularity, around 1-2 days of work or less, to make it super-concrete.
The team has daily standup meetings, where everyone says what he/she did the day before and what he/she will do today. These meetings last a maximum of 15 minutes. They deal with the super-short-term activity planning. It’s an internal meeting for the Dev Team, so the product owner is NOT welcome, as it would be micro-management.
Agile teams debrief at the end of the sprints
At the end of a Sprint, the Dev Team leads (and team members, if relevant) and the Product Owner/Business Process Person have a one-to-two hour long Sprint review to see the status of the work: if the goals were reached or not, and why. This is an improvement meeting where process adjustments can regularly be made.
Advantages: adjustments to new business requirements are super quick. You get feedback early and based on real stuff, not long lists of requirements with implications that no one seems to grasp.
Agile teams foster accountability
- Courage - admit failures/shortcomings.
- Transparency - communicate about problems to solve them quickly, avoid information retention and power games, create a good atmosphere thanks to fairness.
- To foster transparency, using work collaboration tools like Jira is a great idea. I personally cannot imagine working with my teams without Jira.
- The technical development team is an autonomous entity: they commit on the Sprint goals, and that’s it. The organization they set up to reach the goals is their problem, not yours as a leader — do not micro-manage them.
|Accountability (credit: https://www.flickr.com/photos/okfn/7850188520)|
Agile methods assign clear roles to the team members
An agile Team consists of a Product Owner, the Development Team, and a Business Process Person (Scrum Master for instance).
- Product Owner: He/she defines the tasks very clearly based on business requirements and prioritizes them. The list of work items is called the backlog. He/she is accountable for the delivered outcomes of the project: if the deliverables have no business value, that’s the fault of the Product Owner. The Product Owner is the decision-maker inside the organization for the projects/products in his/her scope of responsibility. They make the call as to what the product must look like, what the work items are, and how they are prioritized. Do not micro-manage the Product Owner!
- Development team: They are all developers. They organize themselves the way they want to, as long as they deliver the Sprint goals. They are a small team of only 4-9 developers, to avoid overhead interference./li>
- Business Process Person: o : He/she ensures the processes are relevant/respected. They maximize communication efficiency among the team by setting up the right processes. They ensure that the Dev Team can stay productive. For instance, if micro-management or conflicting work requests arise, he/she should defend the Dev Team. Usually, a lot of people hate them, because they put their nose everywhere and change stuff. That’s just part of the job.
These are the best tools to support agile processes
- I already mentioned Jira — it’s a great piece of software for organizing your team’s work and reporting it. It helps to foster transparency about the backlog and all priorities. I love it.
- For continuous integration, several tools exist that try to compile the code produced by an Agile team and then report any errors.
- With continuous integration, any code version in the source tree should run without a flaw. These tools come in handy to ensure this does not stay a vague promise. For Java, Jenkins is quite popular.
- To deploy the code conveniently, you need to package your software. If you are familiar with Linux, packages should sound familiar: .deb, .mdk etc. Basically, their role is to ensure all dependencies are installed conveniently when you are deploying code to your computer or server. Docker is a quite popular packaging tool.
Agile methods are quite fun and increase team productivity. Enjoy the ride!