For incremental software development to work, it requires both developers and product owners to be strategic as well as tactical. On the product front, if you just bang out 'feature specs' but without any coherent business strategy you fail. On the development front, if you just implement 'features' but without a coherent architecture you fail. What agile advocates is more subtle - that you should use judgement in order to have just enough business strategy and just enough technical architecture - don't spend forever crafting a cathedral in the sky, but don't just do random crap either. That requires a maturity not all companies have.
Anyone who thinks that agile means not having a strategic plan or architecture is doomed.
I agree that hiring good product owners is very hard - almost everywhere I've managed agile teams, the limiting factor was the lack of product owners who could write stories and make decisions. Most companies are more willing to hire developers and product owners, and I've several times had to beg CEOs to hire more product people, and even shift headcount from development to product management, because they were the bottleneck - you can't implement what isn't defined and prioritized.
If you're an optimist and under-estimate work, that should just come out in the numbers, Work normal hours, see how many points you deliver, then that's what you should commit to next time. Since you take commitments very seriously, you need to be more conservative about how many points you can commit to, so that you can deliver on your commitments in a sustainable number of hours! If you push yourself to work unsustainable hours, you're not doing anyone any favors - you can't produce 80 hours of work every week - you burn out and productivity drops below what you'd be doing at a sustainable number of hours, hurting the team.
The goal of agile is to measure and maximize productivity by minimizing waste. If "doing agile" is increasing wasted effort and reducing productivity, you're doing it wrong.
Ouch - five projects in parallel for one team? I'm starting to manage a team in that situation, and we're thinking that the right thing to do is to turn it all into one big project, with one backlog, so the team is working on one workstream, and it's up to the product owner to juggle the competing projects' priorities, sequencing, etc.
Of course, that's not about "agile" or "scrum" it's about having a culture of trust vs a culture of manipulation. When people use the term "sandbagging" that's a bad sign. Everywhere I've managed, we had developers own estimation, and nobody who wasn't actually writing the code gets to have any opinion about how long something should take to implement. And if a team never takes actual team historical deliverables into account in their planning process is doomed.
This discussion is why I'm a fan of using "points". When you estimate in "hours" people tend to equate "estimated hours" to "real hours" and get emotional - if the team is only doing 4.7 hours a day of work per person, what are they doing the rest of the time? With points, you've abstracted away that issue, and saying that the team does 16 points per sprint, so it's just a measurement of observed velocity to use for planning future sprints, without the emotional baggage.
The trick (IMO) is that instead of exactly defining a product before committing to it, you define a goal and manage to hit the goal. The military does this all the time - your goal is to take control of an objective, and it's up to you to work out the tactics based on the situation, available resources and competition. Similarly, a company should invest in "Enhance product X to satisfy market demand for capability Y, and make $Z in new sales" but shouldn't have detailed screen shots or specific customers named - it's too early for that. You need to identify lead customers, partner with them to learn what they really care about, iterate towards that getting their feedback, and of course make sure that they're willing to pay for what you're doing for them.
Yes, this requires the team to think strategically and make decisions. Agile doesn't work well with people who don't do that.
Hopefully it should. It's all about transparency. If the developers are hitting their commitments, but customers aren't buying the product, that's not the developers' fault.
Agile isn't just about the development team - the whole value stream from idea to product in the marketplace has to think differently. For example, product management shouldn't spend a year specifying a product in a huge Market Requirements Document, they should have an idea, whip up a mockup, show it to potential customers, and get their feedback - if the product is a bad idea, kill it and move on to the next idea, so you haven't wasted a fortune building a product nobody wanted. Similarly, sales can become a radar for collecting market intelligence from your customers (or not - learning why people don't buy your stuff teaches you something valuable, too). And it means that CEOs have to get comfortable setting business goals, and trusting them to manage to hit the targets, rather than signing off on huge, detailed product specs with 5 year revenue commitments before a line of code has been written. It's all a very, very different way of running a company. And companies who master it crush companies who don't.
If you're doing a detailed work breakdown of a 6 month project all up front, you're not doing agile, you're doing waterfall. Trying to fully specify everything in advance is a losing strategy, because it's an absurd amount of effort up front, and it forces you to ignore everything you learn along the way. In agile, generally you only want to fully specify the next two sprints' work ('backlog'), so that you have a set of work that you can prioritize and manage. Without a backlog, you're just doing whatever the product owner things of, which isn't prioritized or structured, and barely even managed.
Your example of breaking into major phases (research, implement, fine time, etc.) is pretty good, though personally I'd find something small and research, implement, integrate, deploy, etc. on that small piece first, rather than having a big 'integrate and test' phase for the project as a whole. Have you heard the old joke that "the first 80% of the project is developing the functionality, and the second 80% of the project is integration and testing"... it's much less risk to break the whole project up into smaller functional pieces, each of which go through research, implementation, testing, performance tuning, etc., so that you've got an end-to-end system working all the time, and you're just broadening out the coverage over time.
That's an odd definition of "value to customers" and not one I've ever seen used - though lots of companies do odd things, so no doubt someone is doing so. The point of applying "lean manufacturing" techniques to software development is simply to move work efficiently from idea to completed, shipped code. The work can be user-visible or it can be internal - I've seen plenty of demo's where the demo was a chart of a load test before and after an optimisation, showing that the system had 15% more capacity on the same hardware on the new code. (To use a real example my team showed me last week)
Then you should try to break it down into smaller tasks, so that you can complete a task, and prove it works, in a day or a few days. Huge chunks of code that aren't merged back into source code control / master are dangerous, because the longer you go un-merged the messier the merge will get.
That's time passing, that's not work. If it takes a month for something you ordered to arrive, one task is placing the order, and another task, which you would do a month later, would be to receive the thing and do whatever you need to do with it.
The agile answer is not to make detailed long-term commitments, because in the intervening time business priorities could change, and you don't want to be forced to waste your time doing something that's no longer of any value just because you made the mistake of committing to it. Of course, you can commit to goals, subject to the business priorities remaining the same. But it's smart to avoid committing to exactly how you're going to do something months in advance, because you might find a much better way to do it, or not need to do it at all...
For agile to work, architecture has to be taken seriously by the team, which needs to invest in re-architecting, refactoring, etc., as they go, so that they don't just pile up massive tech debt and collapse.
Agile only works with teams that are relatively skilled and experienced and communicate well. If your team isn't like that, agile might be a bad idea. Or you need to invest in improving the team.
Exactly. Though I have never heard of TDD being "write one test at a time and then write the code to pass the test" - everywhere I've done TDD (and I've been doing it since the 1990s) we've written a whole suite of tests that defined the expected behavior of the system being built, and then written code until we passed that test suite.
Sprints are very valuable, if there's good transparency about stories and burn-down (or burn-up) charts, because they let everyone know how the team is doing, continuously, so if there's a problem and the team is going to miss a commitment, it's visible and can be fixed. And having a regular cadence helps teams learn to estimate and hit commitments, which is valuable for all concerned.
The value of standups is that they give everyone a chance to ask for / offer help, raise challenges, etc., but by doing it at a fixed time every day avoids frequent interruptions during the day, which break concentration and decrease productivity. If standups are boring daily wastes of time, you're doing it wrong - standup should be as short as possible - what tasks did you complete yesterday, what tasks are you working on today, and do you have any blockers. 15 minutes is plenty of time.
Stories don't replace more detailed documents, they are just a short representation of the work for purposes of managing the work. If a story is complex and needs a detailed writeup, or screen design, to make sure that everyone agrees on the details, that document is critical and the story should link to that. But if the developer can ask the product owner a few questions, and that's sufficient and a big written document would be a waste of time. And for big projects, the specifying alone can take a year, which is a year wasted compared to getting something simple in front of users to find out what they actually want in reality rather than in theory.
It's not magic - it's a collection of practices that work well in the real world. And while you might thing that all good developers do TDD and FBF, for example, that's not the case - both those ideas were obscure and radical before XP/Agile/Scrum pushed them into the mainstream.
In reality, lean production techniques are why the Japanese car companies outperformed US car companies for several decades, until the US car companies copied their management techniques and (somewhat) caught up. Very real stuff, worth $billions.
If MBA's don't understand lean manufacturing and copy the form without the substance, the problem is the MBA's, not lean manufacturing.
Exactly. Product managers are very bad at imagining hypothetical future products and completely specifying them, and engineers waste a lot of time building multi-year "cathedrals" that turn out not to be what the marketplace wants. Building mockups, then MVP's, then iteratively enhancing it, all based on marketplace validation and correction works a lot better. If you build a mockup in a few days, spend a day in Starbucks getting users' feedback, and you find out it's a bad idea and move on to the next idea, you've saved a big company $millions in wasted effort compared to spending two years building a robust product that nobody wants. (And that has happened most of the time!) That's one of the key values of agile - listen to the feedback from the marketplace and pivot based on what you've learned.
When done right, it lets managers get out of the way of developers, because it replaces the boss being in charge with the team being self-led, with the "boss" clearing the path and facilitating when things get stuck, and you empower the product owners with real authority to make decisions, empower teams to do real estimation, etc. When I've seen agile fail, it's because the management couldn't give up control to the team, so they basically ran waterfall development using agile terminology. That is, when you make fixed scope and fixed time commitments, because the boss (or product owner) says so, you're waterfall - it doesn't matter if you use story points and sprints to implement your waterfall product, because you've missed the fundamental point of agile.
Call it Scrum, XP, Kanban, etc. - it's all about measuring and optimizing a process by empowering the people who do the work to improve how they do the work. Everything else is just a means to that end. The techniques work, which is why companies who do them tend to outperform the companies who don't. But a bad team with bad management who uses the form of agile without the substance is still screwed.
More specifically, the CBP's position is that they can keep all data that they inspect forever, and her lawsuit would force them to prove that they only used it to inspect her as she comes into the country, and to wipe the data now that they're done. This is an important lawsuit, because right now they're pulling all data from all devices that they 'inspect' (e.g. https://www.theguardian.com/us...) and have demanded social network credentials so that they can log into your account and capture your posts and friends. I'm sure it's all useful to them, but it sure feels unconstitutional, in a country founded on freedom and individual rights.
Nobody's being charged for having an affair. They're being charged (and pleading guilty to) violating election laws (illegal campaign contributions) and not paying their taxes, for example. It's common for investigations to pursue illegal activities discovered in the course of the investigation. And it's not like it's hard to connect the dots between Trump's campaign colluding with Russians and Trump's campaign manager's illegal financial dealings with the Russians, Russian's illegal dealings in the US, Trump's personal lawyer illegally paying people off with campaign funds, etc.
Gitmo is even more insidious. US citizens have legal rights, and so do prisoners. In Gitmo they pretend that prisoners aren't prisoners, but are an invented new label 'enemy combatants' , so that they can pretend that these prisoners don't have the legal protections by the Geneva Conventions, so no laws at all constrain their behavior. This is moronic, because it legitimizes other countries using the same dodge to illegally torture captured Americans. And, of course, US law still applies to the people doing the torturing.
Exactly. Anyone who wants to hide criminal activity can easily do so by keeping it on an internet service instead of on a phone, and there's nothing that border patrol can do to prevent that. Searching phones for (for example) social media posts disagreeing with the government isn't about security, it's about intimidation, trying to scare people into giving up their civil rights because they're inconvenient to people in power. That's not how the US is supposed to work.
While it's entertaining to imagine Apple buying Tesla, because the companies are quite similar in some ways, I think it's unlikely for exactly the same reason. Apple's winning strategy is to control everything that they can, because they are visionaries and perfectionists, and produce products that customers love. Same for Tesla. That makes them fantastic companies, with fantastic products, but terrible partners - they would both drive the other crazy trying to control everything.
Slashdot Mirror
For incremental software development to work, it requires both developers and product owners to be strategic as well as tactical. On the product front, if you just bang out 'feature specs' but without any coherent business strategy you fail. On the development front, if you just implement 'features' but without a coherent architecture you fail. What agile advocates is more subtle - that you should use judgement in order to have just enough business strategy and just enough technical architecture - don't spend forever crafting a cathedral in the sky, but don't just do random crap either. That requires a maturity not all companies have.
Anyone who thinks that agile means not having a strategic plan or architecture is doomed.
I agree that hiring good product owners is very hard - almost everywhere I've managed agile teams, the limiting factor was the lack of product owners who could write stories and make decisions. Most companies are more willing to hire developers and product owners, and I've several times had to beg CEOs to hire more product people, and even shift headcount from development to product management, because they were the bottleneck - you can't implement what isn't defined and prioritized.
If you're an optimist and under-estimate work, that should just come out in the numbers, Work normal hours, see how many points you deliver, then that's what you should commit to next time. Since you take commitments very seriously, you need to be more conservative about how many points you can commit to, so that you can deliver on your commitments in a sustainable number of hours! If you push yourself to work unsustainable hours, you're not doing anyone any favors - you can't produce 80 hours of work every week - you burn out and productivity drops below what you'd be doing at a sustainable number of hours, hurting the team.
The goal of agile is to measure and maximize productivity by minimizing waste. If "doing agile" is increasing wasted effort and reducing productivity, you're doing it wrong.
Ouch - five projects in parallel for one team? I'm starting to manage a team in that situation, and we're thinking that the right thing to do is to turn it all into one big project, with one backlog, so the team is working on one workstream, and it's up to the product owner to juggle the competing projects' priorities, sequencing, etc.
Of course, that's not about "agile" or "scrum" it's about having a culture of trust vs a culture of manipulation. When people use the term "sandbagging" that's a bad sign. Everywhere I've managed, we had developers own estimation, and nobody who wasn't actually writing the code gets to have any opinion about how long something should take to implement. And if a team never takes actual team historical deliverables into account in their planning process is doomed.
This discussion is why I'm a fan of using "points". When you estimate in "hours" people tend to equate "estimated hours" to "real hours" and get emotional - if the team is only doing 4.7 hours a day of work per person, what are they doing the rest of the time? With points, you've abstracted away that issue, and saying that the team does 16 points per sprint, so it's just a measurement of observed velocity to use for planning future sprints, without the emotional baggage.
The trick (IMO) is that instead of exactly defining a product before committing to it, you define a goal and manage to hit the goal. The military does this all the time - your goal is to take control of an objective, and it's up to you to work out the tactics based on the situation, available resources and competition. Similarly, a company should invest in "Enhance product X to satisfy market demand for capability Y, and make $Z in new sales" but shouldn't have detailed screen shots or specific customers named - it's too early for that. You need to identify lead customers, partner with them to learn what they really care about, iterate towards that getting their feedback, and of course make sure that they're willing to pay for what you're doing for them.
Yes, this requires the team to think strategically and make decisions. Agile doesn't work well with people who don't do that.
Hopefully it should. It's all about transparency. If the developers are hitting their commitments, but customers aren't buying the product, that's not the developers' fault.
Agile isn't just about the development team - the whole value stream from idea to product in the marketplace has to think differently. For example, product management shouldn't spend a year specifying a product in a huge Market Requirements Document, they should have an idea, whip up a mockup, show it to potential customers, and get their feedback - if the product is a bad idea, kill it and move on to the next idea, so you haven't wasted a fortune building a product nobody wanted. Similarly, sales can become a radar for collecting market intelligence from your customers (or not - learning why people don't buy your stuff teaches you something valuable, too). And it means that CEOs have to get comfortable setting business goals, and trusting them to manage to hit the targets, rather than signing off on huge, detailed product specs with 5 year revenue commitments before a line of code has been written. It's all a very, very different way of running a company. And companies who master it crush companies who don't.
If you're doing a detailed work breakdown of a 6 month project all up front, you're not doing agile, you're doing waterfall. Trying to fully specify everything in advance is a losing strategy, because it's an absurd amount of effort up front, and it forces you to ignore everything you learn along the way. In agile, generally you only want to fully specify the next two sprints' work ('backlog'), so that you have a set of work that you can prioritize and manage. Without a backlog, you're just doing whatever the product owner things of, which isn't prioritized or structured, and barely even managed.
Your example of breaking into major phases (research, implement, fine time, etc.) is pretty good, though personally I'd find something small and research, implement, integrate, deploy, etc. on that small piece first, rather than having a big 'integrate and test' phase for the project as a whole. Have you heard the old joke that "the first 80% of the project is developing the functionality, and the second 80% of the project is integration and testing"... it's much less risk to break the whole project up into smaller functional pieces, each of which go through research, implementation, testing, performance tuning, etc., so that you've got an end-to-end system working all the time, and you're just broadening out the coverage over time.
That's an odd definition of "value to customers" and not one I've ever seen used - though lots of companies do odd things, so no doubt someone is doing so. The point of applying "lean manufacturing" techniques to software development is simply to move work efficiently from idea to completed, shipped code. The work can be user-visible or it can be internal - I've seen plenty of demo's where the demo was a chart of a load test before and after an optimisation, showing that the system had 15% more capacity on the same hardware on the new code. (To use a real example my team showed me last week)
Then you should try to break it down into smaller tasks, so that you can complete a task, and prove it works, in a day or a few days. Huge chunks of code that aren't merged back into source code control / master are dangerous, because the longer you go un-merged the messier the merge will get.
That's time passing, that's not work. If it takes a month for something you ordered to arrive, one task is placing the order, and another task, which you would do a month later, would be to receive the thing and do whatever you need to do with it.
The agile answer is not to make detailed long-term commitments, because in the intervening time business priorities could change, and you don't want to be forced to waste your time doing something that's no longer of any value just because you made the mistake of committing to it. Of course, you can commit to goals, subject to the business priorities remaining the same. But it's smart to avoid committing to exactly how you're going to do something months in advance, because you might find a much better way to do it, or not need to do it at all...
For agile to work, architecture has to be taken seriously by the team, which needs to invest in re-architecting, refactoring, etc., as they go, so that they don't just pile up massive tech debt and collapse.
Agile only works with teams that are relatively skilled and experienced and communicate well. If your team isn't like that, agile might be a bad idea. Or you need to invest in improving the team.
Exactly. Though I have never heard of TDD being "write one test at a time and then write the code to pass the test" - everywhere I've done TDD (and I've been doing it since the 1990s) we've written a whole suite of tests that defined the expected behavior of the system being built, and then written code until we passed that test suite.
Sprints are very valuable, if there's good transparency about stories and burn-down (or burn-up) charts, because they let everyone know how the team is doing, continuously, so if there's a problem and the team is going to miss a commitment, it's visible and can be fixed. And having a regular cadence helps teams learn to estimate and hit commitments, which is valuable for all concerned.
The value of standups is that they give everyone a chance to ask for / offer help, raise challenges, etc., but by doing it at a fixed time every day avoids frequent interruptions during the day, which break concentration and decrease productivity. If standups are boring daily wastes of time, you're doing it wrong - standup should be as short as possible - what tasks did you complete yesterday, what tasks are you working on today, and do you have any blockers. 15 minutes is plenty of time.
Stories don't replace more detailed documents, they are just a short representation of the work for purposes of managing the work. If a story is complex and needs a detailed writeup, or screen design, to make sure that everyone agrees on the details, that document is critical and the story should link to that. But if the developer can ask the product owner a few questions, and that's sufficient and a big written document would be a waste of time. And for big projects, the specifying alone can take a year, which is a year wasted compared to getting something simple in front of users to find out what they actually want in reality rather than in theory.
It's not magic - it's a collection of practices that work well in the real world. And while you might thing that all good developers do TDD and FBF, for example, that's not the case - both those ideas were obscure and radical before XP/Agile/Scrum pushed them into the mainstream.
In reality, lean production techniques are why the Japanese car companies outperformed US car companies for several decades, until the US car companies copied their management techniques and (somewhat) caught up. Very real stuff, worth $billions.
If MBA's don't understand lean manufacturing and copy the form without the substance, the problem is the MBA's, not lean manufacturing.
Exactly. Product managers are very bad at imagining hypothetical future products and completely specifying them, and engineers waste a lot of time building multi-year "cathedrals" that turn out not to be what the marketplace wants. Building mockups, then MVP's, then iteratively enhancing it, all based on marketplace validation and correction works a lot better. If you build a mockup in a few days, spend a day in Starbucks getting users' feedback, and you find out it's a bad idea and move on to the next idea, you've saved a big company $millions in wasted effort compared to spending two years building a robust product that nobody wants. (And that has happened most of the time!) That's one of the key values of agile - listen to the feedback from the marketplace and pivot based on what you've learned.
When done right, it lets managers get out of the way of developers, because it replaces the boss being in charge with the team being self-led, with the "boss" clearing the path and facilitating when things get stuck, and you empower the product owners with real authority to make decisions, empower teams to do real estimation, etc. When I've seen agile fail, it's because the management couldn't give up control to the team, so they basically ran waterfall development using agile terminology. That is, when you make fixed scope and fixed time commitments, because the boss (or product owner) says so, you're waterfall - it doesn't matter if you use story points and sprints to implement your waterfall product, because you've missed the fundamental point of agile.
Call it Scrum, XP, Kanban, etc. - it's all about measuring and optimizing a process by empowering the people who do the work to improve how they do the work. Everything else is just a means to that end. The techniques work, which is why companies who do them tend to outperform the companies who don't. But a bad team with bad management who uses the form of agile without the substance is still screwed.
More specifically, the CBP's position is that they can keep all data that they inspect forever, and her lawsuit would force them to prove that they only used it to inspect her as she comes into the country, and to wipe the data now that they're done. This is an important lawsuit, because right now they're pulling all data from all devices that they 'inspect' (e.g. https://www.theguardian.com/us...) and have demanded social network credentials so that they can log into your account and capture your posts and friends. I'm sure it's all useful to them, but it sure feels unconstitutional, in a country founded on freedom and individual rights.
Nobody's being charged for having an affair. They're being charged (and pleading guilty to) violating election laws (illegal campaign contributions) and not paying their taxes, for example. It's common for investigations to pursue illegal activities discovered in the course of the investigation. And it's not like it's hard to connect the dots between Trump's campaign colluding with Russians and Trump's campaign manager's illegal financial dealings with the Russians, Russian's illegal dealings in the US, Trump's personal lawyer illegally paying people off with campaign funds, etc.
Ao you're arguing that US government employees treatment of US citizens just across the border isn't constrained by US law?!
Gitmo is even more insidious. US citizens have legal rights, and so do prisoners. In Gitmo they pretend that prisoners aren't prisoners, but are an invented new label 'enemy combatants' , so that they can pretend that these prisoners don't have the legal protections by the Geneva Conventions, so no laws at all constrain their behavior. This is moronic, because it legitimizes other countries using the same dodge to illegally torture captured Americans. And, of course, US law still applies to the people doing the torturing.
Exactly. Anyone who wants to hide criminal activity can easily do so by keeping it on an internet service instead of on a phone, and there's nothing that border patrol can do to prevent that. Searching phones for (for example) social media posts disagreeing with the government isn't about security, it's about intimidation, trying to scare people into giving up their civil rights because they're inconvenient to people in power. That's not how the US is supposed to work.
While it's entertaining to imagine Apple buying Tesla, because the companies are quite similar in some ways, I think it's unlikely for exactly the same reason. Apple's winning strategy is to control everything that they can, because they are visionaries and perfectionists, and produce products that customers love. Same for Tesla. That makes them fantastic companies, with fantastic products, but terrible partners - they would both drive the other crazy trying to control everything.