Your friend Jim George thinks you'd be a great addition to Ricochet, so we'd like to offer you a special deal: You can become a member for no initial charge for one month!
Ricochet is a community of like-minded people who enjoy writing about and discussing politics (usually of the center-right nature), culture, sports, history, and just about every other topic under the sun in a fully moderated environment. We’re so sure you’ll like Ricochet, we’ll let you join and get your first month for free. Kick the tires: read the always eclectic member feed, write some posts, join discussions, participate in a live chat or two, and listen to a few of our over 50 (free) podcasts on every conceivable topic, hosted by some of the biggest names on the right, for 30 days on us. We’re confident you’re gonna love it.
I’m a fan of Agile methods, though I don’t get to apply all of them myself (my projects are solo). I’m not a fan of large scale scrum or other pure Theory Y ideas, as I don’t think every employee is suited to it. Someone needs the oversight to identify bad apples and the authority to counsel them or fire them.
The best answer to the issue of bad apples is that they are “blockers” that management should remove.
My projects were mostly solo, and I thought that made it even easier to do things this way. I never heard it called Agile until after I’d been doing it for years. I was just trying to get enhancements deployed as quickly as possible because the customers like it. If they request a change at noon, and it’s in production the next morning, they like it a lot.
And bug fixes as well, although of course, there were never any of those in my code.
I am not an IT person, but even I can see the value in these practices! I do remember the quality teams of the ’90s and they had their ups and downs. But this approach makes sense. And as a little end user, I approve! Thanks @clavius. You explained it well.
It does seem natural, but does not have the control, reporting, status updates, etc. that management feels it needs to be in control.
And not only do customers like getting things quickly, it changes what they ask for. If it takes six months to get something, you’ll ask for everything you can imagine. If it’s a couple of weeks, you’ll be more focused on what you really need.
I think this role is one of the most important and one most often ignored. I worked off and on for a year on a project where the “product owner” (from marketing) was working with continually with my engineering team to add new features to the product – which we produced. When the time came to to deliver the product, it became clear that the “real” customer’s main interest was the lowest price he could get.
I like a lot about agile methodologies, and very much appreciate the philosophy behind it. I like the dynamism of the rapid-cycle develop-deploy-evaluate-revise process, the way it integrates operation and development to solve the most pressing problems quickly. I’m generally attracted to emergent, rather than top-down, organization, and I think order often arises best through iteration and feedback.
Like @PhilTurmel, I’m a solo software developer. My own niche is machine control and embedded systems, mostly in factory automation. There’s no practical DevOps approach to what I do: that is, it’s hard to do frequent software releases into a distant customer’s industrial equipment, given the nature of embedded controllers, network security issues in clients’ establishments, and the lack of on-site technical expertise. On the other hand, on those occasions when I do get to do more conventional development, I try to embrace more of the fluidity of agile by avoiding overly complicated and rigid initial specs, focusing on rapid incremental delivery, and encouraging feedback. I think it works well, and it’s certainly more fun.
Great post. Thanks!
During the last decade and a half I have worked on multiple projects that called themselves Agile. I have found that Agile can work well, but only when a team adopts it seriously. Most of the so-called Agile projects I’ve been on have adopted certain aspects of Agile without really committing to it. Having a thrice-weekly “scrum” that lasts over an hour isn’t agile. That’s just an old-fashioned status meeting, and by having it more often you’re just wasting even more of your people’s time.
The main problem I’ve seen with Agile is that it is often used as an excuse to not design anything. But Agile doesn’t mean “make it up as you go along.” I mainly work on customer-facing documentation, and it’s hard to write docs when you have no spec and no clear explanation of what will be shipped.
One of things I really like about Agile, though, is that it tends to keep plans closer to reality. When you’re working on a “waterfall” project with a long development cycle, it’s easy to end up with a release plan that is impossible to achieve. Everybody ends up working overtime, and eventually the release gets delayed. With Agile, especially in a continuous-delivery world, you do whatever you can fit into a particular iteration; if you can’t finish it in this iteration, you break it into smaller pieces and move some of the pieces later. That can be abused as well, of course, but I think it does keep everybody a bit more honest about what’s possible.
My Mentor likes to say, “There are some businesses where you can go from concept to product in a day. Florists and candy makers are among them. Someone comes up with chocolate-dipped potato chips. You get down to the end of the bag and realize you have a lot of broken and unsuitable pieces. What do you do? Come up with a new product. Chocolate bars with potato chip pieces in them. It’s fast adaptation. If they don’t sell, you find a new thing to do with them. Caramel apples rolled in potato chips pieces instead of nuts? We can try that. From concept to shelves in less than a day.”
This conversation is an entry in our Group Writing Series under September’s theme of Order. We still have a dozen days open. If you would like to share something about order or disorder, emergent or divergent, come sign up. I saw someone say that Ricochet was now all focused on one single subject, but it isn’t true, and Group Writing is one of the things that brings more interesting topics for us to share. Our sign-up sheet is waiting, and you know you have it in you.
My strategy was to get something in front of the users as quickly as possible, so they can start using it to achieve some of the goals. From that point, my approach was, “what can I do today, what can I do this week, what can I do this month?”.
From a contracting standpoint, this is also nice because the development is never really done. Even after you’ve achieved all of the original goals, they’ll have thought of new things. And given that most environments now seem to be constantly changing, your software must continuously adapt to the new environment.
This is true of every new method-of-the-week that comes along. Many projects that were being called Business Process Re-Engineering were nothing like it. If you’re just laying people off, that isn’t BPR.
You are correct that Agile is often used as an excuse not to plan or design. That tendency is a permanent fixture in system development. With each new technology, be it relational databases, client server, whatever, many people take it as an excuse to throw out the care that is required to build a quality application that can be maintained.
You are also on point with the tendency to be “Agile in name only.” That is a huge risk as people resist change and so just change the names of what they do instead of changing what they do. We had a consultant recently tell us about a project they joined where their daily stand-up lasted eight hours. It was just a long group working session.
Putting code into production is the best way to keep people honest and plans closer to reality. You are spot on.
Here in Japan, it has been weird being involved in pilot Agile efforts a couple years back, then being away from them for a time, and now wanting to be back involved in them again.
(I consult in enterprise process improvement [both “upstream” from software projects, as well as at the interface between org dev and project implementation], along with software project management, and requirements/backlog elaboration and management.)
There are increasing numbers of Japanese who do indeed “get it,” and more importantly have a constructive idea of how to make “it” work in decidedly Japanese enterprise contexts. This is a fortunate thing.
The unfortunate thing is that the IT professional services category called “SI” or System Integrator is profoundly dug in as a difficult-to-circumvent “partner” in developing and operating enterprise software systems here, and the “SIer” business model (and the legal framework for contracts) is at base inimical to a healthy, fast-moving, and intelligently risk-conscious approach towards advancing Agile.
I’d like to think that SAFe (Scaled Agile Framework, in its current v4.5 form) could help dislodge the SIers and transform the relationship dynamic between enterprises and their IT professional services vendors, but the SIers here are “going to the mattresses” against such attempts — while simultaneously, of course, portraying themselves in the PR arena as embracing Agile.
In any case, I would heartily recommend Mark Schwartz’s books, in particular his most recent one “A Seat at the Table,” as a way of re-setting executive-level thinking about the why’s and wherefore’s of Agile as it relates not only to IT managerial leadership but indeed in conjunction with corporate/enterprise leadership and business strategy future directions.
In our move toward Agile, I find that the most resistant to it are the people who were formerly identified as “business analysts” and now are trying to be “Product Owners.” The actual production owners are being kept at arms length. The “PO’s” in put team are still trying to steer certain tasks toward certain people, to the point where they won’t put anything in the “ready to work” lane until they know who is ready to pick it up.
Otherwise, I think it’s working well in our shop. I used to be pigeon-holed into one system, now I get to work in different areas.
#14 MeanDurphy
Hugely valuable comment re the PO’s reluctance to OK dev work until assured of who’s assigned to the work. (Depressing, but valuable.)
Weak executive sponsorship? Weak ScrumMasters?
The observation about BA’s being in limbo and attempting to re-cast themselves as PO’s is something I’ve seen; personally, I don’t consider it to be imprudent or heretical to experiment with such role shifts, but the risk as I see it is business-side PO’s lazily delegating everything out to “deputized” BA’s acting as their representatives to the dev teams. That simply replicates the pre-Agile paradigm, and allows PO’s to evade accountability into the bargain.
Mark Schwartz’s books are great!
It is ironic that Japanese SI companies struggle with Agile since so many of the principles of Agile arose from The Toyota Way.
That is a hard transition. Better to make the BAs team members who do backlog refinement and testing and maybe even learn some coding.
And cross-functionality is great.
Exactly.
A good BA should have started as a coder.
I can’t argue with that.
I can. Not talking about Agile, but in general. The best BAs I’ve seen are attractive young women. Not super-hot, but attractive. Because their job is to get other people to describe their jobs in detail. Women prefer to deal with women, as long as they aren’t too pretty. And men enjoy being the center of an attractive young woman’s attention.
That does not mean they can’t have a base of coding experience.
Didn’t say they can’t, just that it’s not necessary. Out of the group of four that I have in mind, one of them had taken some classes in college.
Agile – Back in the ’80s we called it “prototyping”.
Of course, in the 1970s cloud computing was called “timesharing”.
Everything that’s old is new again.
Generalized Management Handbook:
1: Centralize that which is decentralized. Decentralize that which is Centralized.
2: Wait 5-10 years, then repeat #1
Ha, so true.
I very much like this post and I think you described the basic concept clearly. I also identify with the topic having worked in two giant international companies. I’m not IT though. I worked in industrial and energy operations and in quest-technical roles that used software and had to deal with bungling by management and the sometimes erratic nature of the clients. I have come to believe that a flatter management structure is frequently much better than a large pyramid of top down orders approach. Only doing what one is told, and the view of individuals having their own ideas as a hazard.
Most managers I’ve seen were mediocre to bad and were frequently clueless on how to add value, so superfluous additional paperwork, procedures, and emails are generated. Calling a meeting or putting out the latest fad thing that will wash out in 6 months is considered an accomplishment. Basically people in an organization structure trying to look like they’re doing something to keep a position or ladder climb. Perhaps there’s a name for this condition. And frequently those other managers that were good or still in the energetic phase of life close to operations didn’t have the authority or means to make required adjustments. And addressing problems frankly and directly could cause problems for those reform minded managers because it might be taken as an indictment on those above and thus damage career advancement through the ranks. I notice that incentives can be a big issue. Things are not always so straight forward and tying to do a good job and helping your company provide a quality service. Middle managers sometimes don’t have the same goals of implementing policies (especially when they are difficult to comply with) from above nor do they necessarily have the incentive to help the workers under their direction. This is a peculiar bureaucratic issue.
I prefer a system when involved members can more readily address issues that are identified – instead of being passive workers waiting to be directed. Having targeted control and authority to correct issues that you and a team deal with on a regular basis rather than waiting for some removed person to take action on something he doesn’t have specific knowledge of or might not even care about. “Hey, that’s not my problem!” It doesn’t mean that a team will always provide the best solution, but it does mean more issues can have solutions not only proposed but worked on. One aspect of real operations in companies perhaps under identified is that time, effort, and resources can get wasted simply because of additional work created by inefficiencies within a system of an organization.
Yes, Theory Y produces better results in almost all situations. Certainly not limited to IT. Thank you for your thoughts.
One of our PO’s has limited coding experience, one actually came from the “ops” (company ops not computer ops) section, the other 3 are variously experienced with Project Management. Our Scrum Master has her work cut out for her, especially with the most senior of the former PM’s. The OPM wants to run everything and has strong opinions on who should be trusted to do what.
mostly they collect requirements, determine priority, and act as liaison to the business.
The ops person isn’t as involved as I would prefer.
Kanban team:
1 Scrum Master
5 PO’s
5 devs (me included)
2 QA/Testers
2 week target for story completion (abt 45% on target)
Supposed to be 1 story per dev, but I’ve had up to 3 (average 1.5 so far)