You’ll find excuses, like “Oh, I’ll get back to it later,” or “Come on, it’s half a point; everyone knows what to do”. Don’t do it.

Realize as you spout these self-platitudes that you are being an arse – not to me, but to future-you and future-you’s team. That’s not cool. Write out the story. It’ll take you two minutes, but it’ll force you to think about what you actually want to get out of this effort and why. That’s rather important in most endeavors.

You only talk at stand-up

I once worked at a job like this and quit after about three months because it was utterly soul-destroying. Most humans want to work in a team, so find a way to work as one. Giving a two-minute, fact-based update in a 15-minute meeting once a day doesn’t cut it, and you risk losing half/all of your team who feel isolated.

Communication is hard. So is software development. So, the idea that we all wander off into our silos for 24 hours once standup is done, and nothing will still be unclear, hard or confusing in the meantime, is just plain silly.

If your team isn’t talking a lot during the day, it might mean they’re all super-humans. Or, more likely, your culture is bad, and they’re afraid or unwilling to communicate. 

Some things that I’ve seen work well to overcome this are Perma-calls, Kick-off chats and setting clear expectations for what junior devs should do when blocked.

Planning sessions of 2.5 hours

Your workload is not an impossible-to-plan anomaly. You do not need several hours to agree on what is coming into the sprint for the next week or two. What is actually happening is that you’re doing planning wrong. 

Instead of a chat that sounds like, “Let’s do these {n} things in the sprint, any concerns/emergencies/issues?” – what is almost definitely happening is that you’re discovering a bunch of new information in the planning session, which is leading to a re-refinement (or first refinement if you’re terrible) of the work.

Instead, do refinements. I won’t go into how to do a refinement; go Google it/read this link. But please do them. One of the hardest parts of Agile development is getting what to work on (and why) properly defined for the whole team. Focus on “defined and aligned.” If your team hasn’t defined what success means and aren’t all in agreement, the story shouldn’t be in planning. Send it back to the refinement stage.

PM-&-lead-only work-scoping

Delegation is easy, but it’s the thing I see most people screw up most often, myself very much included. But it must be overcome if you want a team to get good at planning, scoping and estimating work.

To be explicit:

• Everyone in the team should be involved in scoping out tickets before the refinement.
• Everyone in the team should be actively involved in the refinement session itself.

When teams don’t do this, they’re missing out on a bunch of things such as experience gained for junior devs, seniors learning to better explain and share their thoughts and helping the team internalize the code as something that they own.

Delaying releases until all the stories are done

If you’re not delivering “continuously”, then please go back to 2003. We’re not FTPing our files onto production servers for a deployment process.

The faster you integrate code (i.e. make it part of the main branch) the earlier your team is discovering differences with the code they’re writing. The longer this time-to-integrate is, the further things will have diverged, and thus, the more time will be wasted picking it apart.

The faster you deploy your code, the quicker your work is getting out to your customers, and the sooner you’ll know (if you have a robust error monitoring setup at least) whether you’ve introduced a new bug as part of the work, meaning the time-to-fix is vastly reduced. A nice side benefit is that the less that has been queued up to deploy, the smaller the “deploy diff” will be. That’s going to make it a heck of a lot easier to fix, in my experience.

Bad excuses I’ve heard over the years as to why you can’t do this include, ‘it takes up too much time’ (deploying should be a click of a button), ‘It’s not all ready yet’ (meaning you’re planning your work wrong) or we’re not allowed to because of “X regulation.” For the latter, read The Phoenix Project for some good lessons on how to address concerns here.

Caveat: Sometimes it’s physically not possible to do regular deployments, like if you’re writing software for a cruise missile. But otherwise, if SpaceX can deliver software to their satellites every week, you can do continuous delivery, mate.

We’ll add the tests later

Add them now or admit (ideally in a signed pact with the devil, written in your firstborn’s blood) that you just don’t care about whether your code works or not.

I suspect that if I have to argue this point further, then you’re already too far gone to be saved, but put succinctly-ish: untested code is code that probably doesn’t work. It’s impossible to know if it does work because the tests that should describe the functionality aren’t there. It’s also impossible to change because you don’t know what you’re breaking when you change it. Untested code is immediately legacy code that must either be immediately fixed (with tests) or completely replaced.

The post Bad habits that stop engineering teams from high-performance appeared first on SD Times.

After many iterations of planning at different time scales from daily to yearly, I’ve finally come to understand the source of my lingering doubt.

As the person responsible for a team’s planning outcome, I realized that I’ve always had to serve two distinct audiences: the stakeholders, and the team of builders. They have different goals when it comes to planning, yet without explicitly stating them, as I was subconsciously swaying between satisfying one or the other, that’s when the doubt of insufficiency crept in.

To be effective in satisfying both audiences, we have to dive into what they’re in for.

The Stakeholders

The typical stakeholders of a software building team include higher level managers, other teams, their managers, and possibly executives. If they’re ever part of a team’s planning, chances are, they are there to find out, and possibly negotiate, what will be done by when.

For higher level managers and executives, this is important because, as the ultimate resource allocators, they have to keep an eye on the return on their investment, in the form of people and time. For example, knowing how many engineering weeks it would take to integrate with an external service provider might be a very important factor in them deciding whether they’d make the purchase.

For other teams, participating in planning is important to coordinate their dependent projects, as well as benchmarking their own project execution. It could be a customer-facing team interested in when the next version of an internal tool will be released, or it could be a sister team about to start a similar migration and is interested in how much effort there would be.

Ultimately, stakeholders’s goal from planning is to gather information so they can make future decisions. As a result, the view we present to stakeholders during planning should focus on expected outcomes – what will be achieved, in what order, by who, by when, with what value, and what risk.

The Builders

On the other hand, for the people who are actually building the software, they mostly come to planning simply to receive their next batch of work.

The game for them is simple. The more details and certainty there is, the more predictable and smooth their execution will be. In the most extreme case, if every single piece of requirement and specification is laid out, with all the edge cases accounted for, and assurance that nothing will be changed, most engineering teams can deliver exactly what is being asked for with high accuracy. On the other hand, if there are many ambiguities over how a system should behave, especially in unexpected situations, the room for poor design and execution gets larger and larger, to a point where entire systems may have to be redesigned and rebuilt from scratch.

As a result, experienced engineers will be on the lookout for ambiguities during planning and will attempt to clarify as many points of contention as possible to avoid going down the wrong path.

Therefore, the view we present to builders should focus on scope (i.e. what concrete behavior the system should exhibit, ideally with priority of importance) and design (i.e. what technical components or structure needs to be there to afford the behavior), so they can have confidence to deliver their work.

Coming together

In summary, the stakeholders want predictable outcomes, while the builders want enough details to get their work started. But.. how can the team commit to an outcome without sufficient details, and how could there be concrete scope if important decisions about the project were not yet finalized?

That’s right. It’s not possible.

It’s not possible because I may have tricked you into assuming planning is this one full day, or at most a few days, of non-stop meetings where all decisions are rapidly made and all plans are readily finalized for a quarter or even a year.

But in reality, a well thought-out plan has to be an iterative process. Product team needs time with customers to develop and validate ideas. Product and engineering needs time together to converge on a compromise between functionality and feasibility. The technical team needs to evaluate design options and trade-offs. Analysts need to pull numbers to assess impacts and risks. Managers need to negotiate with each other on personnels. Department heads need to align on wider priorities.

All these conversations take time and rounds of back and forth to reach a conclusion. That is where the real planning happens.

If you’ve taken the time to have these conversations, hopefully you wouldn’t feel as inadequate when the new quarter starts.

The post The two faces of software planning appeared first on SD Times.

The post Industry Watch: Planning for the perfect appeared first on SD Times.

As CIO and cofounder of Amadeus Consulting, John Basso has seen this time and again over the past 21 years. In that time, his firm has learned how to align software development and business objectives, and now has released ID-GEM, a free planning tool aimed at small- and mid-sized organizations that might not have the expertise to find the business value in a software project.

(Related: Requirements must keep pace with agile)

“Look at people building a home,” Basso said. “The architect wants to build something to make people happy, but people often ask for illogical things. So you walk in the house and say, ‘Who would build a hallway this narrow?’ It’s illogical.”

In the same way, he said, a technology company is being paid to do what its customers want, and often is torn between building what they want versus building what it thinks the customer needs. “Often, though, they don’t know how to ask that question,” said Basso.

He cited a 2015 Standish Group report that said that only 29% of software projects are successful, and “clear business objectives” were identified as a key factor in project success.

“People jump right into requirements,” said Basso, going from what they think their needs are to defining software features without taking time to consider if the software will meet the needs. “But they have to build the right thing. You have to look at the technology part, but you also have to look at the business part.”

Basso said there are five steps to ID-GEM. The first is to identify value and a primary business objective. “You want to create users or capture market share,” he said as a simplistic example. “So you can’t put a 17-page login system in place, as your adoption rate will be horrible.”

Next, the process calls for asking questions related to the primary objective, such as “How will we make it easy for users to sign up?” or “What is your user acquisition strategy?”

Step three is to create an initial goal. In this example, the goal might be to gain more users. An improved goal might be to say, “I want 1 million users by Q4, achieved through social sharing and referrals.”

After that, Basso said it’s important to evaluate the outcome and see how the solution performed against the established goal.

And finally, you need to measure the success of the solution, with the business side and technical team collaborating. “Big Data is only valuable if you use it to drive business value,” Basso said. The data might find that 18- to 20-year-old males drive more social user acquisition between 9 p.m. and midnight on Fridays and Saturdays, and the company needs to determine how it can leverage that information and continue progress toward the goal.

Amadeus has made the software free of charge on its website, delivering a custom PDF of the ID-GEM framework that can serve as a repeatable process for each software project.

The post Amadeus emphasizes best practices in planning tool appeared first on SD Times.