3 things I learned about Agile
As a non-technical person who has come into the world of software development, I want to raise what I see because we are applying agile principles to traditional business practices and its an eye opening experience.
The first thing I noticed is that agile and traditional business practices share similarities but with very different outcomes. For example, scrum is an agile method. There is a daily ‘stand up‘ which is essentially a very fast planning meeting. Where typically in business you would book a room, sit round a table and waffle for an hour, with scrum that meeting takes place in less than 15 minutes for a team of 10 people. It is an immediately visible increase in efficiency and it has the added benefit of acting as a team bonding exercise on a daily basis. Most weekly management meetings cannot say they incur the same efficiency or effect.
To follow through with efficiency and effectiveness, agile teams make their work visible on a scrum board. The principles of openness and transparency is truly refreshing. It’s an excellent tool for monitoring work, watching throughput and managing risks, obstacles and distractions. Everyone knows what each other is doing, everyone plays a part and everyone gets the job done. And as a business management tool it is excellent for empowering teams.
At Energized Work we go one step further and apply agile practices to traditional business work like product development, business planning and marketing. Typically, we serve clients who are often undergoing digital transformation and so have incumbent cultures that find adopting agile practices challenging. As we are currently undertaking the building of our own digital products internally we are applying agile principles across all work types including managing our marketing trials using sprint practices.
On a scrum board developers can see work that they can do within a sprint, which for us is typically a week or two long. Nothing that is unclear, poorly defined or without acceptance criteria progresses to the ready column. But, other people in the team like designers, marketers and business analysts have different challenges. They work on tasks that have a different rhythm because they are awaiting business decisions or working with customers and it creates a different flow.
We have learned that for our small product team, the differing work flows don’t seem to be a problem. A card can be in progress with an estimated time for conclusion. We add work items whether coding or other and manage them accordingly. Equally our backlog is ongoing. We adjust cards when we are clearer and groom the backlog as we go.
Business objectives are critical
Interestingly enough, the process works because agile and management intercede at the point of objective setting. This is the biggest learning of all. Clear business objectives are critical. Tell us what the goal is and we will work toward it under the steward of a product manager and the scrum master will keep the product manager and team honest.
When working with a client business decisions are left to the client. Today we are having to make our own business decisions based on the direction of our product and it is not easy. Its obvious but often overlooked that business objectives are the most important component of digital product development – not the technology. The only advice I can give is that if you’re using agile in any shape or form but do not have clear measurable business objectives defined, then stop what you’re doing and get that sorted out first
Thankfully, agile is a method of iterative working and has fostered other good practices like Lean thinking which grapples with business decision-making. We’re in early stages and we’re still iterating, learning and deciding one small step at a time. Let’s see what happens as we grow.
Featured photo by pHsquared