Staying agile
 |
| source:twitter |
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Agile software development at least to me isn't scrum or kanban or safe or less or more or short or fast or pace or... I am open to any framework that fits the context and can adapt to change.
Last week Friday one of our dev thought of a feature that could enhance the experience in our app (Friday Morning). The 6 of us in the team voted if we all found it useful. We recokend it could take us about 40 min to bring it to life.
Friday afternoon we picked the stuff required to demo the feature in action. It did mean we had to eat katsu curry two day in a row. Build more stores Maplin. Over lunch built, tested, setup demo data and practised our secret gig. We were very careful to not share it on any channel not even a mention of it.
Friday evening demoed all our prioratised delivered cards from the board and followed it with our usual ... One more thing ....
Product owner and other senior members in the company now want to roll it out at the next event.
Product owner and other senior members in the company now want to roll it out at the next event.
So did we do anything different? The way I see it - we stayed agile.
Comments
- Is this because you hired the right people, and your delivery team now know where the value is so well, that the Product Owner role is starting to become unnecessary? Ok, maybe the role is needed, but an individual with specialist skills to do ONLY that role, is not needed?
- If the above is not true, then did you step outside of the core intention of delivering the most valuable thing? Did the team simply achieve that goal by accident?
- When is it right to go off piste? We have to assume that people always have good intentions, so how do you delineate between proving a point, and wasting time that could be better spent? - I appreciate that there may be too many variables to answer this fairly, for example.. "The team did this in their spare time" ... 'Why?' ... "Because they are passionate about the success of their product"... 'So why not do one of the things that the users/product owner/business has asked for?' ...etc..
- Is this a point about agility? Or empowerment? :-) is there a difference? I don't think there needs to be, but I wonder if that's part of your point?
..I could continue, but I guess my last question would be around what would have happened if it had failed? I'm fortunate enough to work in an environment where a failed idea is embraced... And I suspect from your post that you do too. How can this be used by those who are not so fortunate?
Thanks for a great post though.
As a team we have the confidence to fail (did not happen overnight) which gives us the strength to believe, back our ideas and bring it to life.
Very good question - Why keep it a secret? (you also follow that with lot of options) -
1. surprise - it's a nice thing. People like surprises
2. cut the noise - processes help but sometimes get in the way
3. market - a bit of showmanship in demos help to sell ideas.
I will not go into detail on your assumptions/questions. My 2 cents on other stuff.
- right people in the team? - yes, but its more important how the team communicates.
- different roles required/not required - always change with context. As in the blogpost to me context is more important and that should decide the roles required and not just frameworks.
- why not just do what is asked of them? - my favourite - I would say this has lot to do with us being humans. This will defintely go into a post of its own :)
- If we failed? - we would had lost about an hour and ate too much katsu curry... sorry ;) But still would be meaningful and a lesson learnt
- For those who are not so fortunate to fail? - I am very bad at generic suggestions. But if teams are afraid to fail for trying out new things - time for a new job!