CTO to SCRUM Master transition
I'm the CTO of a small software startup, and the only original code developer.
I've sponsored the adoption of agile methodology in the team, actively through external training.
At least in the first phase of adoption I see myself as SCRUM master.
My first challenge now is that the newly formed and empowered 3-young developer team+the young product owner are proposing a complete different framework for the application and a rewrite from scratch of the code, rather than continuos improvement.
I understand that as SCRUM Master I would not even question such a decision.
However, I have many doubts, first because even if the team has at least one talented programmer, he is at his first experience. Second, I think that they underestimate greatly the amount of work to be done and the compatibility with the pre-existing work planning (old customers, short term new customers etc). And finally because I think their main motivation is "laziness": they simply don't want to waste time to understand old and crappy code,
Honestly, from a technical point of view, I also see the old code as crappy, and I would also be in favor of a rewriting over starting from scratch, and reasons to stick with old code are few and weak.
But I would like to check myself several technical points before taking such a decision, or I would like even to discuss with them technical details.
How should I deal with this situation?
(or maybe it's just a stupid thing I'm doing?)
What degree of automated test coverage is currently in place for the system?
The billion dollar question!
Will creating new code from scratch deliver business value every sprint?
And what to do with the existing code that is already in production? It needs to be maintained until it can be replaced by working new code.
I had experience with a team that wanted to build new software again from scratch. They discovered a lot of problems and delivered several sprint not any working software,
Finally it was decided to build on the old code and refactor it on going. That worked better. We spend half of the velocity on refactor stories (improving existing software) and half on new features. So we delivered every sprint working software in production, maintained the existing software in production and on going got better software architecture and removed or replaced the crappy old stuff!
But it was really a big effort to get the team motivated to this :-)
A lot of success
BTW this was a team of 9 developers of which 4 -5 where experienced but also very difficult to convince for new ideas
The strategy Gemma is depicting here is also the one I'd go in favor of.
If I switch to my software engineer hat I'd say the team should study the book Refactoring Legacy Code and make up its mind about the strategies to do so effectively.
My thoughts you're wearing two hats: CTO and a Scrum Master. Being a CTO, you're also a stakeholder to this project. So the PO should be encourage communicating with you and other stakeholders, and should, ideally, share the same values are you have.
And the answer should be driven by your business case and, in particular, ROI providing the product expected lifetime.
very very little.
And unit testing would be difficult to implement without first proper refactoring.
In my point of view, that's probably one of the strongest point in favour of rewriting with unit testing included from the beginning
I like your idea of thinking about "value delivered in every sprint".
Refactor old code ongoing and build/mantain is what we have been doing for a couple of years and IT HAS produced value.
However it's hard to keep people motivated, because it's not THEIR code and they feel it's just a mess.
Indeed I will probably willing to accept a rewrite if the new team is committed to deliver "value" at each sprint.
> very very little.
> And unit testing would be difficult to implement without
> first proper refactoring.
>
> In my point of view, that's probably one of the strongest point in
> favour of rewriting with unit testing included from the beginning
Never mind unit tests for the moment. What about automated business tests now? Wouldn't they be a sensible investment irrespective of the underlying implementation?
what do you mean exactly with "automated business tests" vs unit testing?
I'm talking about using feature files to drive automated business acceptance tests, commonly used in Business Driven Development (BDD). It sounds like a test harness is missing altogether in your case, and that this might be a sensible thing for the team to invest in, irrespective of the implementation.
Your Product Owner and Development Team want to re-write they whole application, and "as Scrum Master you would not question their decision". Fine, but you should remind them of their responsibility to deliver value each sprint - how do they propose to do that?
In particular, how well does your Product Owner understand their role in maximizing the value of the teams work? How influential are they with the business - will the business support and survive a period of reduced velocity of new features? Can you coach them on this topic?
In my experience refactoring your existing code turns out better that re-writing unless the business is proposing a fundamental change in the product. Could they use refactoring techniques like the Mikado Method or others and be sure that their codebase improves with every story that they write? It sounds like the Product Owner is aware of the technical debt. Can they prioritize stories to address the problems in the current backlog?
The Scrum Pulse episode on Technical Debt seems very relevant to this
https://youtu.be/cb5fkftdD9k
Posted By Steven Mackenzie on 31 Oct 2016 10:18 AM
Your Product Owner and Development Team want to re-write they whole application, and "as Scrum Master you would not question their decision". Fine, but you should remind them of their responsibility to deliver value each sprint - how do they propose to do that?
In particular, how well does your Product Owner understand their role in maximizing the value of the teams work? How influential are they with the business - will the business support and survive a period of reduced velocity of new features? Can you coach them on this topic?
In my experience refactoring your existing code turns out better that re-writing unless the business is proposing a fundamental change in the product. Could they use refactoring techniques like the Mikado Method or others and be sure that their codebase improves with every story that they write? It sounds like the Product Owner is aware of the technical debt. Can they prioritize stories to address the problems in the current backlog?
Hi Steven,
I'm aware mostly everybody is cautious with re-writing. In our case business is not asking for fundamental changes but I foresee need for more flexibility and our architecture is not extensible enough. Actually it's too naif to be called an architecture. We arrived so far with refactoring and the fact that architecture is naif means that is also relatively easy to read (but not to touch).
Plus we are aware many functionality developed are now probably updated or useless.
At this point I would say my doubt it's not really to refactor or not to refactor, it's more: how can I sell it to the whole team and how can I keep the business going at the same time.
I like your suggestion, focusing on delivering value on each sprint. It would be like to be able to show a shining new thing every sprint, even if the final result will take some time....
Really late to the convo :D
I think it's important to remember that a Scrum Master's role is to remain neutral. Being a CTO and an SM is a conflict of interest. You should work with the PO to set a definition of success as a stakeholder (outside the view of the team) to deliver and have the scrum master understand your expectations on technical debt and scalability.