I know we had a thread a couple of months back about BA's - thought i'd start a thread for all those BA's/PO's/Developers/Scrum Masters out there (and i know there are a few) who have been sucked into the Agile world.
I am relatively new to Agile -maybe a years experience now primarily as developer/scrum master, and have achieved my CSM, and have just come off a course for writing Effective User Stories.
I am trying very seriously to move into the Agile World full-time now- seeing that job opportunities seem to be much more healthy within Agile than not.
I am also meeting up with one of the Agile Gurus from the States next month who is a regular Podcast writer for ThisAgileLife.com, and also have started reading a book called Scrum Mastery by Jeff Watts which is extremely good.
,
Too many I's - should maybe be starting some paragraphs with 'As a ' !
Whats your experience with Agile/Scrum? - and what has been your thoughts/experiences so far (maybe in comparison to Waterfall development)?.
4
Comments
Stu, what you've written is all gobbledigook. If you'd written this post ten years ago, they'd be sending round the men in white coats.
Get yourself a real fecking job.
Do you have an ineffective user story that may help?
With Waterfall, you're guaranteed to ensure the solution works, because each incremental piece of work is tested against deliveries. But it's also almost certain that, by the time it's delivered, customers don't need it any more.
Biggest problem in my experience is that big corporations don't have the bottle to see the dev plans through - "I know you said we'd launch when we all agreed we were ready, but is it ok if we give you a hard deadline?"
The notion that a co-located delivery team will be available in a modern cost cut world is bollocks.
It is hocum.
Doesn't work in the real world.
I'll go into more later, but if you do not feel like it is a good (not perfect, nothing is perfect) collaborative way to build and deliver better software then there's a good chance you're doing it wrong. And when done wrong, it's just as, if not more rubbish than anythin.
Failing that try sellotaping some bacon to the garden path - that tends to transcend the gollum slop and keeps the Buddhists on track too
Myself I am by absolutely no means qualified, just fall into the trap of working in an iterative way, but wrongly thinking its 'Aglie'. Couldn't tell you the difference between the two - just found that if the work involves any combination of sprints, backlogs, a Kanban board and stand-ups I go into 'Agile' mode. (Agreed that this sounds like, and may well be, complete and utter jibberish)
As for working, I do actually like it better than waterfall as it feels more creative and when it works, I've found it works really well. But I bet it's frustrating as hell for those at the sharp end of the stick on the occasion that they're told by some jumped-up consultant (even worse if it's a UX consultant) that the work you were asked to do, "yeah, now was actually want it to do X instead".
The key benefit with Agile is that it makes release cycles so much shorter because you're working on smaller work packages. This is a huge thing for end users, who have previously had to wait for all their requirements to be fully built and tested before they get to use it. DevOps takes things a step further, with the idea of continuous delivery and collaboration across the whole lifecycle, including operations.
Personally I reckon most developers love being freed from the shackles of waterfall, and there's much more scope for creativity. The challenge lies in balancing risk, and whilst such things work brilliantly for companies like Spotify (look for their youtube vid on this, it's fantastic) it's a much different challenge in larger and regulated companies. But I do think the concepts aren't likely to go away very quickly. The world has changed, and companies wanting to be first to market can't wait for traditional linear lifecycles and delivery.
How naturally I slip into consultant mode.
I have worked in all kinds of Agile environments, from introducing it to a start-up 7-8 years ago yo failing with Scrum and Scalable Agile Framework (SAFe) at a change-resistant insurance firm a few years back to joining and then creating companies that created an "Agile Culture" over the past few years. So, I'm all in on this.
First and foremost (and sorry if I turn into teacher/presenter here), Agile has four key tenants:
-Individuals and interactions over processes and tools
-Working software over comprehensive documentation
-Customer collaboration over contract negotiation
-Responding to change over following a plan
At its core, and its founding, that's kind of it. There is more in the "Agile manifesto" on self-organized, empowered teams but most people don't get that far. Under this, you could run anything. You could even run very documentation-heavy processes, and I'm currently on an Agile project that is in the midst of a 6ish week research and analysis phase (we've inherited a clusterfuck of a legacy migration). But as we build our team, we follow those principles and I'd say we're following the basic principles of Agile pretty well.
A lot of people confuse "Agile" and "Scrum," so I wanted to call out what Agile is before getting in to Scrum. Scrum is a type of Agile, and there are various types or "methods" you can use (Kanban, Crystal, Lean, etc). Scrum is built around traditional "scrum ceremonies": daily stand-ups, defined length sprints at the end of which working software should be delivered (usually 2 weeks), team/customer demos, planning and retrospective meetings at the end of those sprints, rinse and repeat. Scrum is great for projects where you feel like you can break things out into roughly two week increments (sometimes it's a week, sometimes it's four). In my experience, most projects can be.
But for the Product Owner, Scrum Master, and stakeholders, a sprint is not the end of their ambition, they should have a backlog that spans weeks, and is brought up with the team (usually in a "Grooming Meeting" which is increasingly part of the Scrum ceremonies) regularly. I find that that is where a lot of projects fail, and I say that as someone who has been a PO ~90% of the time, and who has fucked projects with lack of preparedness. Within that backlog should not just be your future stories, but should also be your "customer management" as well. It should be where you point to when they ask "where's my thing?" It should be collaborative with stakeholders before it even gets to the team. And it's the first way to make stakeholders feel a part of the process.
Once you get into the sprints, you should have ~60-75% of your requirements in the form of user stories. This is where I find a lot of developers, particularly older ones (sorry old guys), struggle. Many who lived under waterfall for years are used to having "tech specs" that tell them what and how to code things. In Scrum, you basically take away that safety net (because ~40% of requirements are outdated by the time you deliver anyway), and force them to engage, talk to team members, and collaborate on the "How" and POs with the "What."
As a good friend of mine says, "in Agile, everyone is an architect." And it's true, but as you can imagine, that unsettles a lot of people, more senior devs who worked hard to earn a status or title (manager, architect, neither of which are banned by Agile but both of which should carry less direct weight), and to those who are used to being "told what to do" which, contrary to what someone in every company I've worked in has said, devs do not like to be told.
Lastly, it forces Project Managers (actually, if you have traditional command-and-control PMP project managers, it should put them out of a job) and Business Analysts to actually know what they're talking about and to learn some about the technical side of things and to think quickly and dynamically. That is not for everyone, and that's ok. It takes certain types of people wired a certain way to work like that. But it's crucial, PMs, who used to have a lot of the power on how fast a team works, don't have that anymore. That power is moved to the team because a team only signs up for work within sprints they feel they can complete. That power is spread out and shared amongst a group whose job it is to hold each other accountable. And to traditional management and organizational set ups that like "one neck to wring," learning that getting things done is a complicated and intricate process and that they, too, will need to learn more about it can be difficult and confusing as well.
So in the place of the traditional management structures and PMs telling you what to do and when to do it, you build self-empowered teams who work collaboratively and hold each other accountable for what they're doing and when and how they're doing it. And this is really difficult. But a cross-functional team, including Dev, QA, design, UI, etc. is anywhere from 3-8 and should have a sense of collaboration and shared input. This is hardest on really diverse teams, but this can be solved with curiosity. Even if team members don't fully understand what others are doing, ideally they are working together (for example dev and UI are swapping ideas back and forth as things are built) so that they understand where they fit within the building process. And from that, I find that even if someone isn't a dev or QA or whatever, they know when someone is doing well or not. And because so much of Agile is based around communication, just how well someone communicates can be a good indicator.
So hopefully the above gives an outline of Agile and Scrum, but also hints at some of the cultural shifts that need to occur within an organization that "goes Agile." The culture of an Agile organization (or Agile Culture) is imperative for Agile working. Agile flattens everything in a hierarchical sense. People who were bosses before, who oversaw what employees do, aren't bosses much anymore as many decisions are made within a team, and if someone isn't working, I've found that oftentimes the team calls out a person, then eventually begins to ostracize them, and in the end Scrum Master and PO are usually the ones to handle the HR side of things. What I've found is that even with really great self-empowered teams, other parts of a company needing to feel like they have control can ruin everything. I personally feel like if it's anyone's sole job in a skill-based set-up to make sure other people get things done, then they shouldn't be in a job very long. Building software is not old fashioned line-based manufacturing, and you shouldn't need "overseers."
Okay, so I could spend twice what I wrote and more on the cultural side of an Agile organization, but I'd kind of like to know what everyone thinks, and also where they find themselves and their organizations struggling, plus of course any differences you have.
For the last five+ years I've worked in US Government contracting, mostly for the Department of Defense (Military) Family Programs. You don't get many traditionally less-progressive fields than that (Military is all about hierarchy and command-and-control) and I've made it work, and it's really made me believe it can work in any field (though not necessarily every project).
I should note, as I often do with this stuff, that I am a Marxist (meaning roughly a Socialist and critic of capitalism--a structure that breeds hierarchies), a Californian (though I've never worked in Silicon Valley or any truly cutting edge field), someone who is naturally curious and learns different things incredibly quickly, a Millennial (of sorts, in that I'm 30 but I'm on the older end) and someone who does not respond well to authority but responds very well to leadership. In short, I possess the personal prerequisites for Agile. As soon as I started in even mildly functional Agile teams, I knew I was home and that I'd want to do this forever.
But not everyone is like me, and a lot of people I spent the last five+ years working with and building a business with didn't quite have the programming (pardon the pun) for Agile, and yet all have become something of evangelists on the subject. And I've been around this long enough to understand that this isn't for everyone.
Will post more later tonight once home from game you lucky peeps.