Let’s say that you’re a business executive and you’re in charge of building a new software system. Let’s further say that you’ve heard all of the horror stories about how never-ending software projects are. You’ve heard all about the bottomless pits (yes plural) of money that they consume and how terribly difficult it is to work with and get any information out of the developers.
Let’s also say that you really don’t feel like dealing with any of that bullshit with this project that you’re about to manage. Let’s make one more assumption… you don’t have your own in-house development staff (although everything herein will still apply if you do) and you need to hire a team to build the software for you.
So here we are. You need the software built and you possess many, many executive talents. What additional things do you need to know to give your project the best possible opportunity to succeed without at the same time dealing with any of the foolishness and fukkery?
The following three tips for working with Agile teams will give you a firm leg up on accomplishing just that.
The first thing that you’re doing right is looking for one of the Agile methodologies in which to frame the development of your software. This is definitely the correct thing to do but you have to be very, very careful here.
The Agile concept is such a popular and trendy topic these days that there are many, many fake muhfukkas out there who fly under the Agile banner but ain’t Agile worth shit. Where I’m from, this is known as false-flaggin’. Avoid the false flaggers at all costs.
One of the first things we’ll need to do is arm you with the necessary tools to help you identify a false-flaggin’ muhfukka. Because you don’t want to waste your time or your company’s resources on bullshit, we want to remove the false-flaggers right away.
This will allow you to focus your efforts on the remaining teams that really are Agile.
At it’s core, the aim of an Agile methodology is to work with you to deliver working software that adds value to your organization and to deliver that software early and often.
This is vital for you to understand. We’ve learned over the years that a development team cannot take set of specs and go away for a year and come back with software that matches your needs.
Why not? Because in that year, too many things will have changed (market conditions, user expectations, etc.).
To address this, genuine Agile teams deliver software to the stakeholders every week or two. This is an opportunity for the stakeholders to see and use the software for themselves. Based on that usage the stakeholders then give feedback to the team for them to incorporate into the next delivery (which, again, is only one to two weeks away).
Given all of the above then, one of the first indicators of a truly Agile team is their proposed delivery schedule. If a team is proposing to deliver software more than one or two weeks out, then you might want to reconsider using that team. This is a sure-fire false-flaggin’ flag (no pun intended… seriously).
Note that this should happen from the very beginning. Meaning that no more than two weeks after the start date of the signed contract, your stakeholders should have working software in their hands.
The next indicator of a truly Agile team is that the feedback from your stakeholders is immediately included in the next deliverable. Agile teams build software for the stakeholders and as such, it’s critical that the software is evolving and solving the problems that the stakeholders express.
Therefore, right at the very beginning of the process have them explain their workflow for incorporating stakeholder feedback. I’d even go so far as to structure the contract around this somehow. If they start hemming and hawing, snatch the mic and move on. If they’re open to these discussions, you can keep negotiating in confidence.
Truly Agile teams are very passionate about their ability to deliver software in short cycles that are evolving to solve the problems of their clients. It’s a part of their culture and they’re very proud of it.
This leads us to the…
Agile teams always deliver value that you can see. The technical term for this is a vertical slice. What this means to you is that every time software is delivered (every one to two weeks) your team will be able to visibly see and interact with the latest features and enhancements.
Agile teams don’t say things like “we’ll build infrastructure in the beginning so you won’t be able to see anything until we’re done with that, blah, blah, blah.”
As soon as you hear some bullshit like that, snatch the mic. False-flagger on deck.
A genuine Agile team cherishes their power to deliver vertical slices and happily tread into situations that rely on this capacity.
Agile teams ask you what they should be working on. Because no regular human can accurately predict the future, Agile teams will always want to work on the most important features first. This way, once the project is nearing its end, the Agile team knows that it has already delivered the most valuable features to you.
Because the most valuable features were delivered first, this effectively removes situations where the software project suffers because funding becomes low, or you need to move the delivery date forward, or someone gets hit by a bus, etc.
Agile teams always want the most important features done and approved by you so that the bulk of the value is delivered at the very beginning.
The notion of an important feature really means what’s most important to your team. Since you and your team are the one’s who know what will add the most value, an Agile team will want you to tell them what they should be working on.
Likewise, don’t feel like you have to have the entire thing figured out before you can start building the software. The Agile team will help you establish an MVP (minimum viable product) and iteratively grow it into the powerhouse that you eventually need it to become.
Together, you will have a plan that gets your most important features finished first.
That’s all fine and well, but how does it help you spot a false-flagger? Well… if the team is negotiating a contract that involves you agreeing to a “fixed set of features” and positioning for additional fees if you deviate from that original set, it’s a damned good chance they’re false-flaggin’.
Instead, Agile teams have some notion of size and/or complexity and allow you to freely change your mind about things as you learn more. They are very skilled at helping you swap this thing for that thing while still maintaining original scope.
They never try to “lock you in” to a set plan. They’re very fluid and dynamic. However, they will let you know when a new idea will exceed scope, but they’re always open to exploring how to rearrange the original expectations to keep up with evolving ideas and market conditions.
Ok so you were able to find a true Agile team and the contract has been signed. You have a proposed delivery schedule that matches everything I mentioned above and you’re feeling pretty good about things so far.
Can you now sit back on cruise control while your freshly minted Agile team works their magic? I’m afraid not. There’s more for you to do now than there was before you hired the Agile team.
Now you have to unite both forces. You are now responsible for making sure that your stakeholders and the Agile team are humming along in unison.
Pay attention because this next part is essential. It is the key to avoiding run-ins with TMitTB. I’ve hinted at it throughout this entire post. Can you see what it is?
It’s vital that your team actually use the software when it’s delivered to you.
The main benefit of hiring an Agile team in the first place is the opportunity to guide the flow of development by stating what features are most important and offer feedback on the software as it’s being developed.
One of the worst things you can do is throw that all away by not doing your part.
You must have your team ready to interact with the software. Gather all of your stakeholders ahead of time and have them prepared to attend the demo. Schedule time on their calendars in advance for them to interact with the software after the demo. Your stakeholders need to provide their feedback ASAP.
I recall a situation where we were building software for a multi-million dollar client. We would deliver working software to the client once a month. Now clearly once a month was too long between deliverables but apparently this worked out better for their schedules.
Every month we would go in and demo the software and every month we left the software with them to play with to provide feedback. We noticed that whenever we showed up for a demo, they never had any feedback other than the initial comments that came up during the demo itself.
They never touched the software after we left. This was bad and would not work out well for them.
As fate would have it, near the very end of the release cycle, they decided that it’s finally time to start paying more attention to the software. Of course, they discover many tweaks and changes that would make the product so much more usable by their internal workers and their customers.
Of course, it’s too close to the release date now to attempt even half of their requests without seriously extending the deadline and charging them lots more cash. As expected, they’re not happy. It would get worse.
The owner of their company had suddenly taken a huge interest in the project and he was fukkin pissed because of all of the money that he’d paid us. He claimed that the software wasn’t worth shit as far as he was concerned and he demanded what basically amounted to free work.
Luckily for us, we had proof that it was his team that dropped the ball. Even though I personally detest finger-pointing and scapegoating, we honestly did do everything in our power to keep that exact situation from happening. At the end of the day, as the developers, there was only so much we could do. We needed the feedback from the stakeholders and we needed it early and often.
This was a shallow victory at best because the only thing that changed was that he was pissed at his team and us. Nobody won in that situation. We soon lost that client.
What’s the lesson here? Exactly what I’ve already said…
It’s vital that your team actually use the software when it’s delivered to you.
I cannot find words strong enough to stress to you just how important this is.
You must get your stakeholders in front of the software and then gather up their feedback and deliver it to the Agile team. Confirm with the Agile team that the next deliverable will include your changes. Additionally, you must make sure that the current demo software has included your previous feedback. If it hasn’t, the Agile team will have made this clear well ahead of time so that your stakeholders know what to expect.
Don’t skimp on this.
Even though this is implied from everything written up to this point, we need to go ahead and state it explicitly.
The number one tip for using a team firmly rooted in an Agile methodology, is keep your product relevant.
The Agile methodologies allow you to change your mind about things without incurring huge penalties. However, this implies that you’re focusing your mind on the product and the market conditions that surround it.
You must be more present now than ever before. You gotta keep up with the other leaders in your space, the users in your space, and any other thing that you can think of that could potentially affect the success of your project.
You must constantly reorganize and prioritize the features as necessary so that the Agile team is always working on the most important thing.
How will you know what the most important thing is at any given moment if you’re not keeping up with whats going on in your space?
Take advantage of the fact that you can make changes to the product painlessly when some market condition does something unexpected. Why spend tens of thousands of dollars just to build a product that’s not relevant? Who benefits from this?
Not you, that’s for sure. Neither does the Agile team. If the client isn’t able to be successful with the product that’s delivered, the team that built it cannot be proud of their efforts. The prime directive for an Agile team is to satisfy the customer.
Traditionally, software systems have failed because of sloppy programming and development. What a shame it would be for your system to hit the market without a fighting chance of success because you didn’t have your shit together enough to take full advantage of the awesome Agile team that you were able to hire.
You have to lose the notion that the software development team is responsible for the shape of the software. This is entirely your responsibility. Hell, it’s the number one reason that you want an Agile team in the first place.
You want someone to work with you who understands the nature of software development. The Agile team should be your right hand of power to bring your solution into existence.
But remember, that’s all they are. It’s your solution and you’re responsible for its guidance and direction. You.
You, you, you must constantly reorganize and prioritize the features as needed so that the Agile team is always working on the most important thing.
The only way you can do that is if
You cannot be an innocent bystander in this process. You must take an active role in making sure your team does their part so that you can effectively prioritize features and keep the Agile team producing the most value.
So make sure that the teams you’re considering are really Agile in practice, not just in name.
Once a solid team has been chosen, do your part in working with the Agile team to build the product.
Remember that by continually using the software as it’s delivered (every one to two weeks), your team will be able to reshape the product as necessary. With the software in their hands, thoughts will begin to take shape and solidify. You will discover things that were maybe a bit fuzzy at first.
The Agile team will build the software in such a way that you can change your mind about pretty much any aspect of the final product. You will have a very tight feedback loop (one to two weeks) to make sure your thoughts and ideas are current and on track. This will ensure that the software is relevant and you’re not writing articles about TMinTB.
On the strength, if you follow these tips, your projects will run a lot smoother and be more successful.