DIY agile for 🦖
i’m adding yet another “what agile is and what it’s not” article for google to rank hoping to persuade the rest of dinosaurs to adopt some of the quick wins that will lead your team to agility immediately. Yes, i’m contradicting myself with regards to the previous story. Change is about quick wins too, especially if quick wins help change managers (agile coaches) to get their foot in the door and make a point to top management.
Though in those quick wins we are not talking about “real agile” but just about moderate steps towards lean organization and empowered teams.
Important. Skip reading:
if deliverables in your organization are mapped to organizational strategy and regularly measured based on value for end user;
if deliverables are always very well described and that description is transparently available to all stakeholders;
if scope of deliverables expected by end user do not change over project life;
and if you can predict the change in scope early enough.
However, if you recognize one or another regular pain in the description above, let me tell you that employing some agile techniques & tools will solve it once and forever within a timeframe of about 3–9 month (depending on which type of 🦖 your organization is and in which area you work (research vs operations).
The easiest way to achieve basic agility is to get a team, currently working on an existing product with promising scaling opportunity, get an experienced agile coach like me (he-he) and carefully watch the rollercoaster of emotions within the next months during early morning dailies, exciting reviews where you will see some MVPs real fast (yes!) and get some painful feedback from retrospectives.
If you do not have a coach (yet), try these DYI steps to start addressing all 4 points mentioned above.
1. Map deliverables to organizational strategy (aka OKRs)
How often did your team members tell you that they would like to understand how exactly their activities and projects contribute to the major strategical pillars? Or what is the latest focus and discussions on the Board level?
If not so often, it is either great, because all of your employees are motivated and challenged to deliver results to the “bigger product” and they know which one, or they gave up and are just making sure that at the next yearly review a green tick can be safely put in all the boxes.
So, if you want to give your team more sense of impact or try out a new goal setting technique, try OKRs, Objectives and Key Results. Yet another way of figuring out value from our actions and measurable KPIs to achieve them. The major difference to yearly goals is that the Objectives are exactly those top priorities of the Board like sustainability, customer centricity etc and key results are numbers which are very ambitious (achievable by 60–70%). Usually OKRs are created for 3–6 month and are reassessed regularly in the same cadence.
Those top priorities “cascade” down the departments, where teams get a chance in the first iteration to come up with own ideas how to contribute to the objective in order to meet the goal. Then those ideas are iterated at the management levels (similar to yearly project pitching, right?). And once objectives are fixed, the teams know what they are working against and the Board gets valuable input from the bottom from the teams that are close to the end user.
Start small, as most of departments already have the yearly goals at hand, try to measure it a bit more ambitiously and discuss the proposal with the team.
Once the team commits, go to the point 2.
PS. you can check how companies like google use OKRs too. It’s fascinating.
2. Describe deliverables and make sure they are transparent to stakeholders (aka release or sprint planning).
Now that the team knows the impact that it delivers to organisation, time to refine the product/project goal.
Is it still consistent with the strategical pillars? Has product canvas been created? Where is that long list of MoSCoW prioritised features that hopefully came from interviews with your users (see point 4)?
In the excel? Great start :)
As a true fan of agile, i would prefer using Jira (or any other digital task tool of course) straight away. But for a successful dinosaur i would recommend finding a long white wall in the office (or whiteboard tool if your team is remote) and get some post-its.
Put down all those features on the post its using the value orientation for the user while describing what you would like to see as a deliverable. Normally it can be written in form of a story (and that’s in agile frameworks it’s called “user story”). Basically it’s a piece of the user journey that would solve a current user pain.
Let’s try.
“…as a howtodinosaur reader i would like to get more insights of how to start with agile techniques and get results fast and safe with minimum time and money invest, so that i can implement it in my organisation and create a truly innovative product”.
Would it be a good user story? Probably, if you carefully apply all the tipps i will be giving here or ask for a consultation.
A much better story will be
“…as a user of product X, i would like a seamless integration of my experience with the product through all devices, so that i can access the same information and not lose time by searching for it again”.
Very important in any story are acceptance criteria. Often they are already partly described in the story. Those could be
- i want to access product x from iOS and Android and Windows
- i want to be logged in same session simultaneously
- … and so on
Take some of the new requirements and try it with your team during next team meeting.
Those stories are prioritised in a list called backlog and every release and sprint the team commits on what product increment will be delivered by the end.
3. Change of scope (aka Backlog)
Received an urgent email from the boss or another department head with an unexpected task for your team? Sounds like change of scope that does not belong to the current task list, right? There are many creative ways i have seen how team leaders treat such situations in non agile organisations.
The different way would be to clarify why and how exactly it will provide the value for end user (see tipps in step 2) and put in on the top of the backlog for prioritisation to save it for the future sprint, as the team should not be interrupted.
In case something very urgent has to be considered in current sprint that may impact the whole value of the product, make sure you replace the user story of the same scope of effort and put it in the backlog instead.
4. Predict the change (aka reviews and early user feedback)
There is nothing “better” than a solution that the user doesn't want. Surprisingly enough, there are still so many of them, especially legacy systems of dinosaurs. And if employees are ready to tolerate them, having excel workarounds or not having any choice at all, most external end users will go for a competitor.
Avoiding 2 rules that everyone knows: involve your users early on (before your backlog has been created) and start with the actual interview of the pain (you would be surprised how many of your colleagues would love taking part in interviews) costs a lot of painful product launches and startup failures.
Try getting in love with your user (Amazon calls it customer obsession, but we are not there yet)
Once the team gets close to the real user, conducts “what is your current pain” interviews, collects in to backlog, prioritises with the user and goes for the first release or sprint,
don’t forget to put a blocker in users calendar to visit reviews of the releases, so that the users can explore early stage prototypes and give first feedback, praise and critics. (yes, prototypes are way better than powerpoint project plans, even if they are low-fidelity).
Embrace the opportunity to give users what actually solves their pain and be truly customer-centric.
That was a long one today.
If you read so far, i must admit that this is the 4 steps framework that some organisations consider “real agile” and some of the products i transformed were happy with agility after these quick wins. There is more value in agile enterprise, so keep tuned for more dinosaur stories.
