đź’Ş The Power of Iterating đź’Ş
What “business” can learn from IT engineers
In 2010 I landed my first job for grown-ups: a role in product management at a large financial services provider. This company had just started an “agile transformation”. I believe this transformation was followed by a couple of subsequent agile transformations in the same decade.
This particular one was aimed at getting “the business” and “IT” to work better together. “The business”. I hate this generic proxy. It is so often used (and abused) to describe some sort of anonymous, higher power.
“The business wants this.”
“I just checked with the business and they feel this is extremely important.”
“We need to confirm this with the business first.”
Sound familiar?
Statements like these should be treated as a red flag for any development team looking for meaningful input and feedback on their product.
When you’re building a product for a diverse group of users, there’s no place for a monolythic “business” pushing a direction (or, at least, there shouldn’t be 🙂). People have a name, a role and, accordingly, an opinion. This opinion needs to be put in perspective relative to all other opinions and validated with the actual users of your product.
That being said: For ease of reference I’ll use “the business” to describe anyone outside of the development team in this article. It is a generic term that people still relate to. I’ve lost count on how often it’s used on LinkedIn. But I digress.
Everybody agile!
Agile is increasingly being used outside of the product development domain. In the last decade agile ways of working have been implementented in traditional “business” disciplines. Interesting examples I’ve recently come across:
- An editorial team writing a monthly magazine;
- A team of marketeers organising a live event;
- A group of technical engineers redesigning a maintenance system for trains;
- A group of teachers organising (and running) their teaching curriculum;
- A sales team selling banking products.
By introducing an agile way of working (KANBAN or Scrum) and going through the associated ceremonies people are now “agile”. But the thing is, it should never be about the framework you use to get your work done. It’s about the mindset you develop and improve on. As a team.
In the examples listed above I’ve noticed three things consistently go wrong:
- Insufficient scoping of work. Work is not sliced into small tasks and it is unclear to the team when something is “done”.
- Work items stay “in progress” for a long period of time. Daily updates are identical (“Just like yesterday, I’m still working on x”);
- Limited feedback loops. There’s little (if any) feedback at the end of the sprint cycle (demo) and there’s no feedback opportunity on a daily basis;
So what can these “business” people — sales, marketeers, support, designers, product managers, senior management — learn from engineers? Especially as they explore their new way of working in this ever-expanding era of agile?
There are two essential agile practices engineers have mastered which every team should immediately embrace:
- Encourage peer reviews
- Iterate, iterate and iterate some more
Encourage peer reviews
IT engineers use pair programming and code reviews on a continuous basis. All details are open for discussion, code is rewritten and reviewed again by peers before any sort of product is deemed “done”. This practice increases quality and fosters a culture of open, continuous feedback and teamwork. We are, as a team, responsible for the quality of our product.
Don’t do anything just by yourself. Pair up with someone who can help you improve. Someone with more experience, someone who might be better than you, someone who has a complementary skillset, someone who is really good at giving feedback or someone who can just help you out with the bigger picture.
Too often “business” will go on a solo voyage. Conduct some market research, jot down findings, set up a product or decide on a direction without inviting detailed and continuous feedback during the process (yes, I’ve been guilty of this too).
Team up with others, invite feedback and assume you’re always wrong. It is OK to be humble and ackowledge there are other smart people in this world.
Iterate and iterate and then iterate some more
IT engineers have mastered (and institutionalised) iterating on their work. Every check in of code can be seen as the next iteration of the product. Multiple times a day. Code will be reviewed, checked for quality and accepted (or not). On a larger scale, every demoable / deployable product increment is a new iteration which can be promoted to the next development environment (DTAP) multiple times per day.
Nothing is good enough following a first attempt. Or a second. Never. No matter how brilliant you are.
Iterate fast and often on your product, whether this product is made of code, design, copy, a pitch deck, legal documentation or marketing materials. It is the only way to get it to the next level fast. Additionally, demo your results to everyone. Get out there and be transparant about your progress, even if it sucks right now. Ask others what they think and how you can improve. And, if push comes to shove, you can always use another excellent IT practice: park insignificant feedback on the backlog 🙂.
Happy agile transforming!
