Same! I run the engineering department for a medium sized software consultancy, we're on contract with several large enterprises. In terms of output, we run circles around their internal delivery teams. Not because our engineers are better than them, we've just fully embraced shape up as our development process.
This has also let us bid on projects as fixed rate instead of T&M since we budget time as appetite instead of how long we think something will take to build.
There are still some hurdles we have to overcome, like we can still run into unexpected things that we didn't know about during the betting process, but deep behind the philosophy of Shape Up it feels like something that translates extremely well to more creative R&D development projects like what we do.
In case you are interested in Shape Up and want read more about it, Ryan Singer - the inventor of the methodology - has written a really great book about how they have been, and currently are, building and shipping products and features at 37signals.
The book is called "Shape Up" (doh) and the electronic version is totally free:
In addition to the roughly standard 2-week scrum teams I work with, I am also working on launching a from-scratch project with two developers, and our process is roughly:
1. I keep a backlog of new features that are needed.
2. The backlog items vary in completeness/specificity from "mostly there" to "a sentence or two description". Some of the items are large and need to be subdivided.
3. At any given time, the devs each have 2-3 items they are actively working on.
4. The items range from a day or two up to a week or two for the really big ticket items (e.g. "get performance in boundary cases from 'won't load at all' to 'loads in < 10 seconds'")
5. When a dev puts something in for code review, if they're down to too few items, they check in with me to figure out what to add to their active list. We go over the outstanding list to figure out value vs. effort and make some choices.
Item 5 generally happens weekly, sometimes even every few days. They work fast.
That is the only way I have worked across 3 employers. I hope I never have to work in arbitrary time-boxed 'sprint' units or something. I never understood the appeal outside of pretty specific circumstances.
Sprints should give natural points to present to the end-user. Presenting to the end user is essential to getting feedback, and getting feedback is essential to building something the end user will actually use.
You can get feedback without sprints. But they make it easier, and encourage getting something in front of a user fast.
In fourteen years I've never seen a scrum project that includes user feedback.
At best it led to a stakeholder demo where some business people would look at a form or something, ask some minor questions, then a new cycle would begin (with its context switching, planning stress and perverse JIRA games - all the negatives of Scrum).
I don't think many companies use such regular user feedback in their development process.
Perhaps it's that they don't need to? I actually think a lot of company dysfunction happens when the "official" system purports one set of goals (user feedback, regular pivots) but the "real" system purports others (executive driven initiatives, long sales cycles)
Most of the scrum projects I've worked on have been for mass internet users, where feedback came in the form of AB test results. Our current scrum process includes close review with customers, albeit not on a strict two-week/sprint basis.
On this project we're presenting to users two to three times a week -- not to the same user, the most frequently that we demo to a single user is about every two weeks, but there are a few we exchange notes with weekly.
The "betting table" reminds me that I continue to think there's a large, mostly untapped market for good internal betting and prediction market software in large software companies. The primary problem around them seems to be psychological: it's very, very painful to lose a bet that feature X will be shipped by date Y in state Z, and even more painful to see your own track record of failures grow over time, even if you are also accumulating successes.
I like this concept – when isn’t a commitment a bet that we can achieve Z by date Y? To make it concrete is not dissimilar from the other gamified features different work planning tools have been adding in recent years
Your point about seeing the inevitable lost bets add up is well taken, though from what I have seen the healthy responses to loss tend to be close to “either we win or we learn”.
So you want your team to make smarter bets and win bigger over time, and/or learn more from their losses. Can a software product make that process anything but a burden? Is there more there than other types of performance incentive systems?
Symantec, which once sold programming tools, tried a unique approach - scheduled maintenance. The product team worked on one product at a time. When they finished an update, they'd go on to the next product. Products were not updated out of cycle.
I know these have their place in complex projects, but I'm often intrigued when people don't just apply the natural human instinct of talking about something and doing what needs to be done.
There almost seems to be a fetishistic obsession with referencing some magical method honed by masters of the craft.
When you have more than a few people, “talking about things and doing what needs to be done” breaks down. You can end up in analysis paralysis (endless talking), wild west (everybody doing their own thing and not doing things that work together), wild hares (doing things that aren’t important) or even all three.
And 4) individuals engaging multiple people or multiple people's worth of org resources into their initiative, only to get bored with it half-way in.
And 5), which is why we called this pattern a "do-it-cracy" in our Hackerspace - someone might do something and get 90% done before other people notice, and when they do, it turns out >50% of them absolutely do not want it, and would've objected given the chance.
(Then again, we've found that "do-it-cracy" can arise as a rebellion against excessive bike-shedding, which is something groups of people love to do.)
I'm a newb PM and at the moment I feel like I have all three... It's hard to coordinate when developers are all headstrong seniors with big agendas. The best I can do at the moment is nudge some of them, occasionally, into doing some of the work I need, while hoping their goose-chasing eventually produces something I can sell to my bosses.
As a sr eng, they've also probably experienced a bunch of PMs before, some good, a lot less so, all with their pet projects and agendas that next year will be entirely new and innovative and in the bin in 12 months.
The best ones I have worked with are competent, they dont make me do their work, they keep their promises, they dont waste my time, they see organizational issues and take point on them, and they generally were unflappable in targeting organizational discomfort about tackling an issue or talking to so and so.
This is really hard for someone jr to the space, but humility in the face of everyone's priorities is a great start.
> next year will be entirely new and innovative and in the bin in 12 months.
Yeah but my problem is that they are the ones with grand visions that may or may not ever come to fruition, and I am the one left with half-baked features that the business clearly needs to fix right now but are seen as unfashionable to work on.
Recently I was at a point where I've suggested to onboard a junior resource to mop the metaphorical floor. I'm starting to think that, next time, I should ask to have different degrees of seniority in the team to make it more balanced.
Honestly it sounds like you have a bit of a management problem if your engineers are building random stuff you don't need. I spend a decent amount of my time behind the scenes with the PM folks making sure the things we are building are the things we want to build, and then convincing people (often in a face saving manner) that what the business wants is what we all want (since they pay us.)
This generally works because I target the smaller companies and so actually making money is at issue, in a large enough org you can go half a decade before anything shakes up dumb stuff.
> but I'm often intrigued when people don't just apply the natural human instinct of talking about something and doing what needs to be done.
A few people might do that informally, sure, even as part of something bigger, but there’s no escaping the needs to 1) coordinate over shared resources and 2) organise around shared commitments. And where do those commitments come from? Implies some kind of strategising, and if that’s not a collective thing, then you’re relying on someone doing the telling. And of the options that are strategised, what’s acceptable and what’s outside our purpose, identity, etc?
There are theoretical limits on what formal organisational systems can achieve in terms of information flow (so managers shouldn’t over-depend on them), but nevertheless, the above activities are fundamental. Take any of them away and you no longer have a viable system, one capable of ensuring it’s ability to maintain itself, to act independently, and to increase possibility in a changing and perhaps hostile environment.
Disclosure: I have a book coming out on this stuff shortly, bringing some decades-old, well-tested, and well-regarded theory up to date. FWIW I also wrote one of the leading books on Kanban (2014), not that this changes any of the above, apart from that Kanban is among other things an effective coordination system (though incomplete in the above terms, but then so are all the others).
> There are theoretical limits on what formal organisational systems can achieve in terms of information flow
Well put. There's just too much going on in some organisations for leadership to make meaningful decisions. Your comment reminds me of the Viable Systems model, which was a welcome gem hidden away in (the other) Michael Jackson's systems thinking slab of a textbook.
My go to means of ensuring that executive (including me) can keep their finger on the pulse is to encourage people to be open in large and informal chat platforms like Teams and Discord.
You can only be productive 'talking about something' if you understand the concepts to later 'do what needs to be done'.
In the absence of tech leadership it might as well be magic. I wouldn't understand the working details of doctors or lawyers on a medical, or legal, project but you'd bet I'd be praying to any agile deity listening to drag it over the finish line, trusting that the profit margins would help obscure this uncomfortable reality.
> Scrum with 2 week sprints may work very well in larger corporates, but startups who need to pivot regularly and change direction may not be as well suited to such a fixed process.
If your pivot frequency < 2 weeks, sprint length is not the problem.
Our (complex physical product in a combined design office / factory) method: 10 minute chat together in the morning, identify any problems we'd like help with, anyone can ask to change focus at any time. Sometimes a team works on the same problem, usually people take sole responsibility for something on their own but take it from and bring it back to the group to keep everyone vaguely aware of where things are going. We may state what we think we'll get sorted for the day and what we're aiming for the next few days or week. Rarely do we look beyond a few days because it's too vague/unrealiable. At the end of the week we quickie summarize what got done by email (way shorter/higher level than git logs). If there's an over-arching goal or time pressure everyone is informed and we work toward it. No forms or friction for lateness, leave, lunch, ordering stuff, printing, etc. People are judged on commitment, ideas and progress. Factory floor and equipment, design office and electronics lab all on site. No management except keeping a weekly journal for the team's aggregate progress, setting some priorities start of week, and compressing updates to stakeholders. Oh yeah, and mobile devices are locked in a cabinet at the front door during work hours - if you don't like it work somewhere else or take the day off.
Might be security/secrecy, but sounds like someone in upper ranks got a bad taste from one bad apple. At first I read the earlier "work someone else" to mean get a different job, but now that reads like "pick another building to work in for the day".
In good hands, any product development process works well; in bad hands, any product development process fails. It is not about processes, methodologies, or frameworks - it is about people and what people do.
My team (3 devs) has been using Shape Up since January and it’s been amazing. I don’t think I can ever go back to scrum.
It allows devs to be creative, do what needs to be done, and ship a real feature. All without any product managers, and zero meetings.
Corporate companies could never imagine not counting all their beans, but man it is so freeing if you have the option.
Same! I run the engineering department for a medium sized software consultancy, we're on contract with several large enterprises. In terms of output, we run circles around their internal delivery teams. Not because our engineers are better than them, we've just fully embraced shape up as our development process.
This has also let us bid on projects as fixed rate instead of T&M since we budget time as appetite instead of how long we think something will take to build.
There are still some hurdles we have to overcome, like we can still run into unexpected things that we didn't know about during the betting process, but deep behind the philosophy of Shape Up it feels like something that translates extremely well to more creative R&D development projects like what we do.
In case you are interested in Shape Up and want read more about it, Ryan Singer - the inventor of the methodology - has written a really great book about how they have been, and currently are, building and shipping products and features at 37signals.
The book is called "Shape Up" (doh) and the electronic version is totally free:
https://basecamp.com/shapeup
I would also really recommend the rest of the books, lots of great thoughts on development and management from actual experience. Also free:
https://37signals.com/books
In addition to the roughly standard 2-week scrum teams I work with, I am also working on launching a from-scratch project with two developers, and our process is roughly:
1. I keep a backlog of new features that are needed. 2. The backlog items vary in completeness/specificity from "mostly there" to "a sentence or two description". Some of the items are large and need to be subdivided. 3. At any given time, the devs each have 2-3 items they are actively working on. 4. The items range from a day or two up to a week or two for the really big ticket items (e.g. "get performance in boundary cases from 'won't load at all' to 'loads in < 10 seconds'") 5. When a dev puts something in for code review, if they're down to too few items, they check in with me to figure out what to add to their active list. We go over the outstanding list to figure out value vs. effort and make some choices.
Item 5 generally happens weekly, sometimes even every few days. They work fast.
That is the only way I have worked across 3 employers. I hope I never have to work in arbitrary time-boxed 'sprint' units or something. I never understood the appeal outside of pretty specific circumstances.
Sprints should give natural points to present to the end-user. Presenting to the end user is essential to getting feedback, and getting feedback is essential to building something the end user will actually use.
You can get feedback without sprints. But they make it easier, and encourage getting something in front of a user fast.
In fourteen years I've never seen a scrum project that includes user feedback.
At best it led to a stakeholder demo where some business people would look at a form or something, ask some minor questions, then a new cycle would begin (with its context switching, planning stress and perverse JIRA games - all the negatives of Scrum).
I don't think many companies use such regular user feedback in their development process.
Perhaps it's that they don't need to? I actually think a lot of company dysfunction happens when the "official" system purports one set of goals (user feedback, regular pivots) but the "real" system purports others (executive driven initiatives, long sales cycles)
Most of the scrum projects I've worked on have been for mass internet users, where feedback came in the form of AB test results. Our current scrum process includes close review with customers, albeit not on a strict two-week/sprint basis.
On this project we're presenting to users two to three times a week -- not to the same user, the most frequently that we demo to a single user is about every two weeks, but there are a few we exchange notes with weekly.
The "betting table" reminds me that I continue to think there's a large, mostly untapped market for good internal betting and prediction market software in large software companies. The primary problem around them seems to be psychological: it's very, very painful to lose a bet that feature X will be shipped by date Y in state Z, and even more painful to see your own track record of failures grow over time, even if you are also accumulating successes.
I like this concept – when isn’t a commitment a bet that we can achieve Z by date Y? To make it concrete is not dissimilar from the other gamified features different work planning tools have been adding in recent years
Your point about seeing the inevitable lost bets add up is well taken, though from what I have seen the healthy responses to loss tend to be close to “either we win or we learn”.
So you want your team to make smarter bets and win bigger over time, and/or learn more from their losses. Can a software product make that process anything but a burden? Is there more there than other types of performance incentive systems?
Symantec, which once sold programming tools, tried a unique approach - scheduled maintenance. The product team worked on one product at a time. When they finished an update, they'd go on to the next product. Products were not updated out of cycle.
I know these have their place in complex projects, but I'm often intrigued when people don't just apply the natural human instinct of talking about something and doing what needs to be done.
There almost seems to be a fetishistic obsession with referencing some magical method honed by masters of the craft.
When you have more than a few people, “talking about things and doing what needs to be done” breaks down. You can end up in analysis paralysis (endless talking), wild west (everybody doing their own thing and not doing things that work together), wild hares (doing things that aren’t important) or even all three.
And 4) individuals engaging multiple people or multiple people's worth of org resources into their initiative, only to get bored with it half-way in.
And 5), which is why we called this pattern a "do-it-cracy" in our Hackerspace - someone might do something and get 90% done before other people notice, and when they do, it turns out >50% of them absolutely do not want it, and would've objected given the chance.
(Then again, we've found that "do-it-cracy" can arise as a rebellion against excessive bike-shedding, which is something groups of people love to do.)
I'm a newb PM and at the moment I feel like I have all three... It's hard to coordinate when developers are all headstrong seniors with big agendas. The best I can do at the moment is nudge some of them, occasionally, into doing some of the work I need, while hoping their goose-chasing eventually produces something I can sell to my bosses.
As a sr eng, they've also probably experienced a bunch of PMs before, some good, a lot less so, all with their pet projects and agendas that next year will be entirely new and innovative and in the bin in 12 months.
The best ones I have worked with are competent, they dont make me do their work, they keep their promises, they dont waste my time, they see organizational issues and take point on them, and they generally were unflappable in targeting organizational discomfort about tackling an issue or talking to so and so.
This is really hard for someone jr to the space, but humility in the face of everyone's priorities is a great start.
> next year will be entirely new and innovative and in the bin in 12 months.
Yeah but my problem is that they are the ones with grand visions that may or may not ever come to fruition, and I am the one left with half-baked features that the business clearly needs to fix right now but are seen as unfashionable to work on.
Recently I was at a point where I've suggested to onboard a junior resource to mop the metaphorical floor. I'm starting to think that, next time, I should ask to have different degrees of seniority in the team to make it more balanced.
Honestly it sounds like you have a bit of a management problem if your engineers are building random stuff you don't need. I spend a decent amount of my time behind the scenes with the PM folks making sure the things we are building are the things we want to build, and then convincing people (often in a face saving manner) that what the business wants is what we all want (since they pay us.)
This generally works because I target the smaller companies and so actually making money is at issue, in a large enough org you can go half a decade before anything shakes up dumb stuff.
> but I'm often intrigued when people don't just apply the natural human instinct of talking about something and doing what needs to be done.
A few people might do that informally, sure, even as part of something bigger, but there’s no escaping the needs to 1) coordinate over shared resources and 2) organise around shared commitments. And where do those commitments come from? Implies some kind of strategising, and if that’s not a collective thing, then you’re relying on someone doing the telling. And of the options that are strategised, what’s acceptable and what’s outside our purpose, identity, etc?
There are theoretical limits on what formal organisational systems can achieve in terms of information flow (so managers shouldn’t over-depend on them), but nevertheless, the above activities are fundamental. Take any of them away and you no longer have a viable system, one capable of ensuring it’s ability to maintain itself, to act independently, and to increase possibility in a changing and perhaps hostile environment.
Disclosure: I have a book coming out on this stuff shortly, bringing some decades-old, well-tested, and well-regarded theory up to date. FWIW I also wrote one of the leading books on Kanban (2014), not that this changes any of the above, apart from that Kanban is among other things an effective coordination system (though incomplete in the above terms, but then so are all the others).
> There are theoretical limits on what formal organisational systems can achieve in terms of information flow
Well put. There's just too much going on in some organisations for leadership to make meaningful decisions. Your comment reminds me of the Viable Systems model, which was a welcome gem hidden away in (the other) Michael Jackson's systems thinking slab of a textbook.
My go to means of ensuring that executive (including me) can keep their finger on the pulse is to encourage people to be open in large and informal chat platforms like Teams and Discord.
You can only be productive 'talking about something' if you understand the concepts to later 'do what needs to be done'.
In the absence of tech leadership it might as well be magic. I wouldn't understand the working details of doctors or lawyers on a medical, or legal, project but you'd bet I'd be praying to any agile deity listening to drag it over the finish line, trusting that the profit margins would help obscure this uncomfortable reality.
> Scrum with 2 week sprints may work very well in larger corporates, but startups who need to pivot regularly and change direction may not be as well suited to such a fixed process.
If your pivot frequency < 2 weeks, sprint length is not the problem.
Our (complex physical product in a combined design office / factory) method: 10 minute chat together in the morning, identify any problems we'd like help with, anyone can ask to change focus at any time. Sometimes a team works on the same problem, usually people take sole responsibility for something on their own but take it from and bring it back to the group to keep everyone vaguely aware of where things are going. We may state what we think we'll get sorted for the day and what we're aiming for the next few days or week. Rarely do we look beyond a few days because it's too vague/unrealiable. At the end of the week we quickie summarize what got done by email (way shorter/higher level than git logs). If there's an over-arching goal or time pressure everyone is informed and we work toward it. No forms or friction for lateness, leave, lunch, ordering stuff, printing, etc. People are judged on commitment, ideas and progress. Factory floor and equipment, design office and electronics lab all on site. No management except keeping a weekly journal for the team's aggregate progress, setting some priorities start of week, and compressing updates to stakeholders. Oh yeah, and mobile devices are locked in a cabinet at the front door during work hours - if you don't like it work somewhere else or take the day off.
The phone thing is weird given you treat everyone like adults otherwise.
Agree. Good reasons, not worth elaborating here.
Might be security/secrecy, but sounds like someone in upper ranks got a bad taste from one bad apple. At first I read the earlier "work someone else" to mean get a different job, but now that reads like "pick another building to work in for the day".
In good hands, any product development process works well; in bad hands, any product development process fails. It is not about processes, methodologies, or frameworks - it is about people and what people do.
I'm a fan of https://programming-motherfucker.com/