Explore a month-long process of
The Process | FAQs | About me | Guaranteed! | Let's get started
I recently blogged about "Projects That Suck": those times when software development eats all your funding, chews months off the calendar, and saps your energy so you feel drained.
I see this pattern all the time and it's sad. It's a waste of money, sure—but it also:
It also undermines the image of software development as a profession, so it makes me look bad even if I'm not there!
Even worse, many software development projects end up never getting done at all! So for all that sucking you end up with a complete waste. An expensive mess.
You're under serious pressure to make things work. Now!
When a project gets in trouble, most teams try to:
Extended long hours don't really help because your people are already working hard, and pushing it just wears them down. If you add more people, getting them up to speed becomes a small project of its own. Finger-pointing and technology thrashing do not actually move the project forward.
Having more status meetings is the worst idea of all. Even when the developers are not personally invited (because you need them on task) they are repeatedly taken off task to provide all the details that get fed to management. It's not like team leads and project managers know this stuff automatically; they have to ask developers, whether it's in meeting or out of meeting. Still a waste of their time and momentum.
"Insanity," Einstein was claimed to have said, is "doing the same thing over and over again and expecting different results." What are you doing differently?
Projects that suck are neither happenstance nor a law of nature. They get in trouble from a combination of:
A planning regime that doesn't take into account the way creative people actually work makes it even harder to recover from mistakes, stay motivated, and maintain high productivity. (Yes, programming is creative work.)
Rest assured, you don't have to put everything up for grabs, but for many shops those very linear methodologies like Rational Unified Process (RUP) or the classic "waterfall" don't work either. They're adapted from manufacturing or industrial processes that have a lot more repetition than anything you ordinarily see in software development. Software is so fluid, often so vaguely defined, and so subject to change, that trying to plan all the details up front is unrealistic and just makes things harder.
There is another way. A better one.
Hi, I'm Mark W. Schumann, the guy who does stuff here at Critical Results.
I've worked with many companies over the years who have adopted various bits of what are now referred to as "Agile" development practices. Agile is fundamentally a set of values that favor:
These values take the shape of twelve principles such as doing very frequent software updates, not overworking, and maximizing the amount of work that you can constructively avoid doing. Those principles are implemented as actual methodologies that various parties have figured out and made to work. A few of well-known ones are Scrum, Kanban, and Extreme Programming.
I've found that Agile is rather poorly understood in most places, as though it were a catchy term for ignoring management and not doing any planning. Thus the cliché: "We tried Agile and it doesn't work."
The whole idea of Agile is that you do what works! If it doesn't work, and you keep doing it, you're not Agile!
The thing is, adopting Agile is really difficult if you just jump in. Even if you read all the great books on the topic. You need help, and when your project is already in trouble you need the quickest payoff first.
![[Emergency Agile logo]](/images/emeragile.jpg)
That's why I created this program I call Emergency Agile. It's a small subset of Agile practices, the ones that you can implement very quickly with immediate results. It goes like this:
![[ WEEK 1 ]](/images/wk1.jpg)
On the very first day, make it a Monday, we start right in with the Pair Programming practice. It's exactly what it sounds like: we put two programmers onto one set of tasks—using one computer—for part of the work day.
Many people find that a little too intimate to do all day, especially in a cubicle environment, and it's something that you're better off being taught by example. So I rotate among your team members at the beginning, taking an hour or so with each one, switching hands at the keyboard as the situation warrants, asking questions and preventing defects before they have a chance to occur.
As the week progresses, we'll put developers together on their own (without me in the pair) more and more. By the end of that first week, everyone will have had substantial pairing experience.
You'd think all this cube-sharing would slow you down. In the very beginning, that's usually true: two programmers working separately may get more code written than two at the same computer. Sure. But the defect rate goes way down almost immediately, which cuts down dramatically on time-consuming rework.
And you'll quickly find that a good pair gets almost as much code written as two individuals; it's a matter of finding a rhythm, learning each other's habits, and developing trust.
![[ WEEK 2 ]](/images/wk2.jpg)
The second Monday, we'll introduce the Daily Scrum standup meeting. Everyone's invited to that meeting, but only the actual team members are allowed to speak. For real.
Scrum is a particular Agile methodology that's all about keeping a project moving forward. A proper Scrum has accoutrements and features like "burn charts" and "product backlogs" and whatnot. I'd be happy to explain them if you'd like. But when you're behind the eight ball, I'm saying that the Daily Scrum meeting itself gets you the greatest positive effect in the shortest time.
Here's how a Daily Scrum goes: Every team member should be there, including developers, testers, and business analysts. The project manager might be there as an observer. Other people—such as you, the project owner—are welcome too, but it is important that the observers stick to observation. They're not there to talk or ask questions.
The gist of the meeting is that I ask each team member, one at a time, these three incredibly simple questions:
That's it! I take down the answers, and we resolve "issues" outside of the meeting. If an "issue" cuts into a developer's (or tester's) time, I'll arrange the resources to solve it so the developers and testers don't get distracted.
It is very important that the team members have no other status meetings. The idea of the Daily Scrum is to keep things moving, and extra meetings interrupt the flow.
![[ WEEK 3 ]](/images/wk3.jpg)
As a manager, the Project Owner, you still need to see what's going on. If you're depending on this software project, status meetings aren't good enough. And it's so hard to get the straight story when it's filtered through a layer or two of management. You need transparency.
An "information radiator" is any kind of highly visible display, in the team's work area, that gives useful (and changing) information to any and all viewers... the same way a regular radiator puts out heat whether there are a dozen people in the room or none. The beautiful thing about the "radiator" is that the information comes to you instead of your having to go looking for it. It really is in the air!
That's why in the third week, we continue the pair programming and we continue the Daily Scrum, but we also try several different ways to make information about the project unavoidably visible to team members, passers-by, and the project owner (you). That might include a modified Kanban board (which I can also explain if you like), a simple task priority list, maybe a wall chart full of color-coded sticky notes for known defects, or something heretofore unheard of.
The point is to make the project visible to everyone at all times. No obfuscation, no waffling in status reports, no half-truths. Information is power, so hoarding information prevents power from going where it needs to. Information Radiators stop the hoarding! They make it really easy to know what's going on, and really hard to provide information that is overly complex, contradictory, or just wrong.
Bottom line: You will know where things stand, what you are getting for your budget, and what's left to do.
![[ WEEK 4 ]](/images/wk4.jpg)
After three weeks of all this change and growth, there will surely be some loose ends, another Agile practice to apply, or at least a need to refresh and review. We plan on a week for that too.
If there is time, we'll set up a Product Backlog (a prioritized list of all the possible product features that aren't being worked on yet) and from that a Task Backlog (a similarly prioritized list of the nuts-and-bolts items that developers and testers have to do). These make great inputs for the Daily Scrum meeting, because a team member's answer to Question 2 ("What will I do today?") can come from whatever's next on the Task Backlog. Thus guaranteeing that your team is always working on the most important things.
My friends and many colleagues are already aware of my finely honed cooking skills. When you get the Emergency Agile program, it comes with homemade Indian food for each Friday's team lunch. My Red Aloogobi (not pictured here—normally a more yellow kind of dish, with cauliflower and potato in a light curry sauce) is already a legend.
Never underestimate the power of home cooking to build work relationships!
So this is Emergency Agile! It's a month-long process of getting your troubled software project back on track, engaging your team in sharpening their skills and motivation, enhancing communication, and making it all transparent to you.
Since I borrow so much from Scrum practices, the ideal team size is around seven members. If more than about a dozen, we might reorganize into two or more Scrums, but the rest of the program works as designed.
Your team will make great strides with Emergency Agile if you sincerely seek success, rather than the ability to redirect blame or to prove a point; if you are strongly biased towards results over methodologies; and if you are very willing to be surprised, because Agile practices aren't like what you may be used to.
Emergency Agile isn't a technical system; it's a system of organization and teamwork. So it doesn't matter what kind of languages, tools, platforms, and environments you're into. .NET, Unix, iSeries, mobile and smartphones... the Emergency Agile practices work regardless.
No! This is a whole month of accelerated development in which the training is in the doing. Everyone's read about Agile, but the way to learn is to see for yourself. Rather than being time away from work, this month is time more focused on achieving your project goals! Quite honestly, this is program is short-term gain and long-term gain. Your team will make more progress in this single month than ever before, and those productivity gains will be permanent.
Me neither! Emergency Agile is not project management, and I'm not a PM. Think coach, not manager; adviser, not boss; partner, not competitor. Your Project Manager's job isn't endangered. It's fortified.
Emergency Agile gets high-impact projects back on track, delivers long-lasting results, and makes your whole team more productive. My fee for the month-long program is $8,895 plus any travel expenses.
I just heard from a colleague who got called in to deal with a project, employing about twenty professionals, that wasn't going well. Because the company couldn't adapt their development process for the circumstances of that project, they finally had to shut it down. With six million dollars lost.
If you think you might need Emergency Agile, you've probably already invested much more than that in your project, with unhappy results. Continuing on that path, even if it appears to be less expensive, won't get the job done. And nothing's more expensive than a project that never actually delivers!
It's not just the money though. When you commit to Emergency Agile, you're involving your whole team in a new way of doing things. It's somewhat informal at times, but don't let that fool you: it's also a lot of work, and it requires a significant mental shift. Agile practices are effective because they cut through the defensive habits and tactics that keep software teams stuck. So you have to really want to change. The motivation to do this is probably harder to come by than the money.
Few other consultancies that advertise things like "Agile Coaching" reveal their fees publicly. And they make you set up an appointment even to find out what they actually do. My costs and program are right up front! I think that's important when information and transparency are essential to the process.
I feel your concern about the price though. It's not trivial, but then again continuing on the path you're on isn't without its own costs. If you're not ready for the dollar commitment, let's hang out on my blog for a while instead. We can talk over your particular situation in the comments.
I'm more concerned it isn't long enough. We're talking about changing a lot of habits here. Remember, Emergency Agile doesn't just move your current project along, it makes your whole team smarter and more effective. It's not that much time considering the benefits.
Do you mean it's not an emergency yet?
Seriously, Emergency Agile is a pretty good way to adopt Agile methods even if you don't quite have a gun to your head. I've organized the four-week sequence with "projects that suck" in mind, but almost every team can benefit from pair programming, the Daily Scrum meeting, and information radiators. It's a great start.
![[Mark photo]](/images/mws.jpg)
I could quote someone who loves me, and I could say reassuring things about my steadfast loyalty to friends and my kindness towards animals, but that's probably not the kind of trust you mean. This is more like will-I-screw-up-your-project kind of trust, right? Well.
I've developed all kinds of software for over twenty years and have personally worked for fifty different organizations in that time, giving me ample opportunity to observe what does and doesn't work. So these techniques aren't just theoretical, or picked up from a book—they're things I've actually tried, refined, and adapted.
Also, my blog has a couple dozen posts about how I approach the Agile concept, how I solve problems, and how I deal with people. You can also get my groundbreaking ("accurate and fun!" according to one executive) paper on the eight reasons why software projects suck and how to make them not suck. (It's an opt-in link. Hope you don't mind.) After reading all of that, you'll have a very good idea of what I do and how I do it.
Wherever you are! My home base is in Cleveland, but I travel well.
Actually no.
I'm telling you, Agile is an incredibly personal thing. Books are good, videos are good, remote is good, but... no. You really do have to be with people and breathe the same air for this to work.
The practices that make up Emergency Agile are proven to get major projects done faster and with far fewer errors. That's why I use it! And it's why I can offer this money-back guarantee.
It's simple; the process works when we work the process. Working the process means:
The guarantee itself is that if the agreed-upon metric goals are not met, I will continue working with your team to ensure that they are. Or alternatively, if it becomes apparent that this just isn't possible, I'll return your money.
I sincerely care about your organization's success. When we work together and get great results, your project succeeds, you succeed and your team succeeds. And when you succeed you refer me. In my business, word of mouth is the best marketing and I really want you to have a great reason to tell others about me.
If your software project is running late or not getting done at all, just fill in this easy contact form and we'll talk. Or just call me. It's 216-661-2000, US Eastern Time. I want to hear from you!
(Feel free to email if you like, but it's probably a good idea to use the phone or the contact form too just in case my spam filter silently muffles your email.)
No pressure. This is all about finding out if Emergency Agile is right for you! If you're really not sure, go ahead and submit the form. It's basically impossible to hurt my feelings by talking it over and deciding this isn't quite what you need. But I'd feel really bad about it if you skipped the opportunity to find out!
Privacy Notice: I will not rent, lend, or give your email address to any third party, nor will I publish your name, without your prior written consent. You'll never get unsolicited email from a stranger as a result of your relationship with me. You can unsubscribe (remove yourself from my contact list) whenever you want.
[ Home ] [ Is This You? ] [ How I Work ] [ My Services ] [ All Up™ ] [ Emergency Agile! ] [ Tech Skills ] [ Who I Am ] [ Case Studies ] [ Contact ]
Copyright © 2005, 2006, 2008, 2009, 2010, 2013 catfood llc