4

Situation: mobile team working with Scrumban on an app. Other products developed in the company.

The lead (who works on more teams), redistributed resources in the team without informing any of the POs. He decided our processes are stupid, planning and retrospective are a waste of time, as he knows best what he needs to do and doesn't need anyone to tell him.

Our teams are self managed, but he takes more of a managerial role.

CEO ok to give him more decision making power, but he doesn't know all the facts.

I can see there negative impact of allowing him complete freedom: no prioritisation company-level, no sync with strategy, team ran by a manager who is sole decision maker.

Question: what would be the consequences of having such a lead in the team? Negative / positive if the case. Trying to make my case for the meeting with CEO.

  • What do the other team members think about the changes made by this person? Do they agree that planning and retrospective are a waste of time? – Bart van Ingen Schenau Apr 2 '17 at 10:39
  • 1
    I'll ask at the retro :) that's my first thing to do, discuss this openly with the entire team. – Andreea Apr 3 '17 at 1:05
4

TL;DR You will end up with a product that does not meet your business need, unhappy employees, and self-organising teams that are dead on arrial. Innovation will also suffer.

Impact on Product

Since the PO has responsibility not just for making a domain decision. They are responsable and accountable for the contents of the backlog.

That has to include not just your business needs but market trends and the commercial needs of your customers. Does your Dev Lead have deep financial and market knowledge? Is he making priority decisions on what the next most important thing to build is based on the whole picture?

That he is undercutting existing PO's shows a significant lack of respect for others in the organisation. That the CEO is supporting him, probably because of his magical technical prowess, shows him to be weak and have a significant lack of understanding of the software development process.

If you are building software products as an organisation it's your CEO's job to understand this, if you just build software to help you ... We'll... It still is...

Impact on self-organisation

Your employees and people thrive in the knowledge based world on three things; autonomy, mastery, & purpose.

The lead developer is undermining the moral and well-being of the organisation by putting this at risk. He has removed autonomy by making decisions on how things are to be done, this undermines mastery as the developers dont own the results. You may save mastery if the engineers are allowed to build good product, but I bet that's difficult in that culture.

Do your engineers feel that they are contributing to the overall wellbeing of the company?

Impact on empiricism

Each of the Scrum events are there to implement empiricism. Without empiricism we are still following a plan driven approach which we know is not effective.

The Sprint Planning event allows you to inspect the backlog and adapt the most effective Sprint Plan.

The Sprint Retrospective allows you to inspect the happenings of the Sprint itself and adapt the way you do things. This also affects self-organisation as it is owned by the team.

Removing these two things removes 2 of the 5 key inspect and adapt points in Scrum.

Conclusion

Without executive level commitment for agility and Scrum any digital transformation is doomed to failure. You need to get your CEO to understand the ramifications and significance of the changes and allow then to decide to be agile or not. It's their choice...but they should try to pick one and commit.

If they waver then chaos is the only winner.

  • This is all theory. In practice many dev teams work on a 'no rules' JFDI way and get the work done. The problem with arguing this way is that he will say 'dont worry we can do all that using my method too' and you wont find out one way or the other for years – Ewan Apr 3 '17 at 6:00
  • 1
    Having done this in practice with many teams for many years these are the actual results of the proposed situation. Granted we don't know all the details, but to claim that "in the real world" chaos rules is not constructive, or consistent with empirical data. – MrHinsh - Martin Hinshelwood Apr 8 '17 at 14:52
  • There is more than can be said on this but @MrHinsh 's answer is very much correct. Recommend accepting. – jason.t.knight Apr 21 '17 at 17:20
1

If all he has done is cut out planning and retro meetings then its not going to be a huge impact.

Plenty of teams skip these. Also, "redistribute resources in the team" is a weird sentence. Your team only works on one project at a time right?

I would be very wary about making a fuss over this. But at the same time, if the planning meeting for example was required to produce a report, say forecast project completion, them he's making his life easier by just ignoring requirements.

I would suggest you offer this guy a PM role. But make clear that it involves more than just getting a team to work faster. He needs to take on the responsibilities (whatever they are in your company) as well as the powers.

  • The team works on one project, but there's another app being developed in the company that sometimes needs Android support. Then they borrow resources from us. The guy is a tech lead for both products. He doesn't want just to get rid of retro and planning, he basically wants to be full manager of the team (from technical decision to strategic and so on), without taking over the PO role that he wants to kill (e.g. he doesn't want to use tickets, dashboard, tracking, estimating, etc.). – Andreea Apr 3 '17 at 5:33
  • If one was building a bridge, housing estate, or doing accounts, then one would be correct; the impact would be minimal. However since software development requires impiricism in order to get the right product then this activity has significant impact on the people, software, and the organisations bottom line. – MrHinsh - Martin Hinshelwood Apr 3 '17 at 5:50
  • thats two projects – Ewan Apr 3 '17 at 5:50
  • If you have to justify having PMs at all then you are playing into his game. Let him be PM and he will either fail to produce the required reports etc or be forced to use some sort of ticketing system. – Ewan Apr 3 '17 at 5:56
  • That's a good option - I am actually thinking about it - but it's not fair towards the PO. I give you an example: the team doesn't use ANY quality standards, we have no clue about code coverage, they use no metrics. I was pushing them slowly towards that (while they build the app, so stuff gets done). The PO is the only one who looks into quality, the PO brought up unit tests, code coverage and pushes for testing in the team. She is doing great work, if I just push her away, it's not fair towards her. That's my dilemma... – Andreea Apr 4 '17 at 2:12
1

The lead developer sounds like he wants to be an old school development manager & have oversight & make a go/no go on all decisions. Rather than a functional manager who manages the people but lets teams & projects self organize. Self organizing teams do, by definition, dilute management control & aspiring managers may struggle to come to terms with the situation especially if he wants to give orders rather than become a servant-leader.

Reading between the lines I don't think that the lead wants to be a PM or PO - he wants to remove agile & install himself as a more old-school development manager instead. From that position he (assumption) would act as a gatekeeper for all development as he (with the CEOs tacit backing) would vet all requests & therefore be able to eliminate pointless work before it got to development.

So I think the lead doesn't like agile & is maneuvering to move back to a more waterfall, command-led structure. Take that to your CEO - if he is happy to abandon agile at least you know where you are.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.