User stories are a critical element of the agile software development process. But they're so different from traditional software requirement documents that many Scrum teams struggle to get them right.
“What do you mean it won’t be ready for another six months?”
“When am I going to see something that works?”
“That’s not the app we wanted.”
“You said you could do this…”
Ever have conversations like that with an outsourced development team? Ever get that sinking feeling when you suddenly realize your project won’t be done on time… if at all?
Some companies think they can’t replace an app with a new version until the new version does everything the old one does.
In my experience, Scrum teams are rarely, if ever, “sitting on their hands.”
Lack of visible progress can stem from multiple factors, none of them good when you’re facing deadlines and expectations.
An ideal vision of a Scrum team is one where every skill needed is represented, along with appropriate levels of expertise, within a single cross-functional group.
This would allow the Scrum team to be completely contained and self-sufficient, never needing to rely on outside resources to complete their production sprints. While this might be feasible for smaller projects with tightly limited scopes, in my experience…ideal situations like this rarely, if ever, occur.
One of the hallmarks of Scrum is the creation of a sort of “bubble” outside your normal corporate hierarchy. This can cause difficulties, of course, when companies first try to implement Scrum. Some of these companies end up modifying Scrum to fit more easily within their existing reporting structures. This is a mistake.
I’ve written a lot about what goes on inside a Scrum team. About teamwork, servant leadership, and empowerment.
I’ve also written about leaders on a Scrum team managing processes not people. How there’s no real “management” in the traditional, authoritarian sense on a Scrum team.
But what happens outside of the Scrum team?
What’s a manager to do?
You need a lot of technical know-how to build an app.
But where does that know-how come from?
Good leadership has always been a key component when building great software.
In the past, Project Managers often held those keys to success. But today’s Agile development methodologies are much different.
Most businesses understand that possessing the right software can increase their overall value. But finding – and by that, I mean buying or building – the right software can be tricky. How could a mobile app, for example, increase your firm’s value?