I think our team will really benefit from being tightly focused on the Next Two Weeks.
I’m starting to read a bit about SCRUM and it seems l;ike a good approach.
There are pieces of the Agile SCRUM project management method that I have had great success with in decent sized projects, in smaller teams, simplify it, and make it work for you. Here are my recommendations:
Daily standup/SCRUM - keep this as short as possible, and do not turn it into a troubleshooting meeting. 10 mins maximum. Only developers and other “committed” people can speak (possibly B.A.'s or content team members) - PM cannot speak, managers cannot, etc.
Sprint planning - keep it simple when starting out… all tasks should be “small”, “medium” or “large”; you can define what each means, overestimate for success! 
Retrospectives - focus on inaccurate task size estimates (solutions: break down tasks into smaller pieces, track trends per developer and address as necessary), task scope creep, cutting scope/functionality, etc.
I’ve been involved in SCUM teams for a few years, either as a developer, or technical architect and I’ve seen it work amazingly well (Nintendo was a prime example of an amazing SCRUM experience) or fail miserably, based on how long the scrums were, and how much time was spent on sprint planning and retrospectives.
Let me know if you have any specific questions… I don’t know of any good resources other than burn-down / Kanban boards in PM tools like JIRA’s Green hopper (there are many others as well)
-Ben
[quote=“Clay_Nichols, post:1, topic:3197”]
Have you used it or something similar?[/quote]Yes, for about 2.5 years now.
[quote]Any suggestions of good resources to learn the practical aspects of it?
[/quote]My favorite is the slim book Agile Software Development with Scrum by Schwaber and Beedle. IMO it’s the best way to “get” Scrum and understand why it is different/better than waterfall.
The good news is, the hardest thing about Scrum is getting management by-in, which you will have. Scrum provides management with more insight into what is happening in the development process, and it expects management to use that knowledge (of what is blocking progress, how fast/slow work is being accomplished, etc.) to take action and make decisions. Think of managing a project using Scrum like sailing a sailboat: you will have frequent opportunities to change tack to bring the boat back on course if it starts heading in the wrong direction.
Even if you find Scrum as a whole doesn’t work for you, its concept of a prioritized backlog of tasks is valuable in and of itself. Does your business have a list of everything it needs to do, in order of most to least important? Just making such a list and keeping it current can be of great value to a business (or project, or even a person). It prompts important discussions and helps prevent working on what is shiny (or recent) instead of what is most important.
Scrum in particular is used in a fairly abusive manner in some places, enforcing daytime start times with early morning standing meetings, planning poker used as commitments instead of guesses, overemphasis on the short term over moderate and long terms.
It also has a tendency to be used to remove authority and self management from engineering culture, removing the abilities of engineering to fix things that need fixing to meet “commitments” which are arbitrary deadlines.
When you use it for something like iOS which has pretty high packaging costs, 2 week sprits can turn into basically 3-6 week of painful dev, 1 week of packaging and presenting to higher ups and retrospecting and cleaning after the last sprint
It works fine on some teams, and goes to hell at other places. SCRUM in particular is a bit too jocular and masculine for my taste. It’s really easy to do something bad with it, but possible to do something good if you’re careful and lucky
@mj_langford, yes, bad management can defeat the best system, no question. However, since Clay is the owner/manager, I think we can assume he is looking at Scrum with the best of intentions and wants to give it an honest try.
The big warning signs I’ve found with Scrum are arbitrary hard deadlines and frequent changes of direction during sprints. Both are signs management isn’t willing to let the process work as designed.
If problems are repeatedly brought up in the daily meeting and not fixed, it is another sign management isn’t committed to making the process work. They were given the information, but chose to not act. I think bootstrappers, feeling every dollar they spend on developers as money out of their own pocket, won’t fall into this trap and will quickly address issues raised.
I happened across this, this morning:
I haven’t used Scrum myself, so I can’t really comment.
Btw, that book is a good book on the idea of what scrum could be 
. See below for my actual experiences with it
bad management can defeat the best system, no question
If you read below, I believe this has happened repeatedly and more often than not.
An Alternative:
Pros: Avoids the pretend estimation that scrum does. Avoids the random deadlines causing overwork (and decreased productivity)
Cons: Still obsesses about velocity and metrics…which is often more about how big a component is rather than true performance of the team
Rant about my experiences (aka, Scrum’s Cons):
I’m not arguing with the contention management can ruin anything. I’m saying it happens a lot with scrum in particular. It’s arcane and ritualistic in ways that don’t necessarily yield useful results, and not due to bad heart’s on anyone’s behalf
Scrum in theory gives a lot more authority to team members. In practice, it’s commonly used to squeeze things into many short deadlines which are surprisingly short for the things that are happening, often causing a lot of long hours and hero crap that shoots project quality to hell. It’s a hot mess of jocular culture, bad statistics, management getting frustrated, and long nights for programmers. This isn’t because management is a dick. This is because management is told to do a lot of weird mode switching that is hard for them to do reliably
SCRUM intentionally has a lot of very sports culture metaphors and short term deadlines that are artificial (the use of “commitments” in particular implies a lot of certainty and personal failing around something that’s just work being done with sometimes complications), and has a lot of “GOTTA MAKE IT FOR THE TEAM BRO”. Timeboxing is used to make urgency. Urgency is used to try to constantly stress the team into sacrificing for the team. This is a sure way to burn people out.
The “bargain” of the team will meet what it says it will for that 2 week period is constantly pushed by management at many organizations, and is often violated by adding elaborated requirements on top of the known requirements at the beginning of a sprint. That said, even the KNOWN requirements are estimated in a boneheaded manner using points from planning poker or point estimate numbers of hours, rather than ranges like we’ve known are needed for good estimation for decades (and with the uncertainty we have in most software projects, the ranges upper end exceeds a single sprint duration). Management takes the scrum “commitments” and turns them into certainties they often plan on definitely having around. This makes failing it worse than it’s “supposed to be” in scrum…
Note, in a normal healthy systems, people EXPECT requirements to crystalize and elaborate as people gain more time with the product. But not in scrum. We only update stuff and the time requirements between the sprints, cause we made commitments. Oh, but we could fail those commitments…but doesn’t that just sound horrible to do? Yeah, it does. So we work longer hours…or get called out as “not a team player” for you know, having families and stuff.
The product owner role in particular is often abused. It’s a non-engineer managing engineers, and as always happens at that interface, they end up disempowering engineering leaders who say ‘No, we have to do X and Y and Z in that order due to how the way this technical stuff works’. So you end up with a lot of overly simplistic under designed systems designed to tick off the ticket super quickly so often, and you have only a guy who literally can go “I didn’t know better” to “make accountable”
Product Owners almost certainly ends up drifting over to a low guy at the management spectrum, rather than top guy in the engineering system. They’re not blamed for longterm engineering failures…cause they’re not an engineer, who end up getting blamed…even though they often repeatedly said X will happen if we don’t Y. POs have little power in the way of stability requirements, it’s all about new feature delivery.
I’ve seen 2 SCRUM teams work, I’ve seen 4 that were dysfunctional. All but one of them had someone who went to ‘actual scrum training’. The 2 that worked were for short projects as well.
I don’t even want to talk about Veolcity, which is one of the most boneheaded metrics ever and is trivially game able anyone who wants to LARP Office Space instead of get work done.
Velocity fails the “Surely we can manage with less people” test: It’s putting a big number up on a wall instead and burning everything at that altar 
Bad systems are bad systems. I’m going to call it: SCRUM is bad, people dislike SCRUM for good reasons, many people who like SCRUM like it because they were doign something even worse before, not because it’s good. The scrum book isn’t a bad read, but the system in practice is not great usually.
SCRUM not a stable system, it’s easy to screw up, it’s got a ton of terminology that makes it more likely to be cargo culted than really implemented as desired, and I’m not sure the ‘golden plan’ put forth in the books really even works super well, as normal humans suck at doing it (and the point estimates really makes me thing it’s rotten at the core).
It constantly locks time, turns estimation into fortune telling, and therefore sacrifices everything else, including employee health and wellness, to get its goals…which it doesn’t even deliver very well for that long…
From the blog post:
For people with anxiety or mood disorders, who generally perform well when measured on average long-term productivity, but who tend to be most sensitive to invasions of privacy, this is outright discriminatory.
I’m guessing from this he has a particular reason to dislike Scrum. I think he might be missing that programmers in general are one of the most measurable (if not always measured) white collar professions: code commit rate, defects per thousand lines of code, etc. are all measurable, Scrum or no Scrum. To try to address what I disagree with in the rest of his article would require an article of similar length. Again, bad management can make things bad, no matter what system is used.
@mj_langford, I’m sorry you’ve had an overall bad experience with Scrum. My experiences have been more positive, but not amazing or perfect.
I do think Clay should read the book and see if Scrum makes sense to him and for his company. He could do worse than to adopt the product backlog, daily meeting, and frequent product review pieces of Scrum and use those with his existing process. There is value in knowing what is most important to work on and being able to quickly identify when development needs something or is heading in the wrong direction.
@mj_langford
Interesting take on scrum in practice.
Of course we love a good bandwagon in software development. I wrote about that some time ago:
Exactly my experience. But then the day job is for a big firm with more manager than programmers, so ymmv.
That said, if you are a small team, do you really need to follow these faddy processes, which are designed more for dinosaurs ?
[quote=“shantnu, post:10, topic:3197”]
That said, if you are a small team, do you really need to follow these faddy processes, which are designed more for dinosaurs ?
[/quote]For small teams where everyone is productive, perhaps do away with the estimating/record keeping, and try the prioritized backlog, the sprints with daily meetings, and the product reviews at the end of the sprints.
Working by myself on my app, I’ve found the prioritized product backlog very helpful. Creating and updating it made me think about what was most important to accomplish for the app. When I had time to work on the app, I was able to pick a high priority item to work on, instead of wasting time figuring out what to work on or spending time working on something not important. It’s helped me get to the point where the app is finished, barring a couple places I need to tweak to improve performance on older hardware.
I’m pretty sure if I didn’t go through the exercise of making the prioritized backlog, I would have some super neat and polished features in an incomplete app.
I would think Kanban (which is what Trello is) would be more suitable for a small team. Or even sticky notes on a whiteboard (the low tech version of Trello)
Completely agree. If you are searching for a software solution, take a look to YouTrack which is a Trello with a built-in bug tracker. I think it is great for software projects (use it for several years). Trello is also good, but YouTrack allows to have a list of all bugs and features, plan versions or iterations and have Trello-like boards for each (they call these boards Agile Boards).
PS: As a new user can’t post links to the post, so just google for YouTrack (product of JetBrains).
[YouTrack][1] looks pretty good. Free for 10 users.
Wich I’d seen that before starting with Trello.
My big problem with Trello is that it’s hard to GROUP a set of related cards.
(You COULD to it a LIST but the problem is that LISTS are generaly used for STATE).
When I feel like being unproductive for a while I may check it out.
