The Great Delivery Debate
By Chris Moody
Dr. Winston Royce first described a model for working with large software systems in 1970, which we’ve grown to know as “Waterfall”. Interestingly enough what many never read in his writings on software development, is the following quote: “I believe in this concept, but the implementation described above is risky and invites failure.” (Source: Dr. Winston Royce. Proceedings, IEEE WESCON, August 1970) Why could he have said this? Could it be that many times requirements are emergent? Perhaps it’s that estimating large and complex bodies of work based on a requirements document can be incredibly inaccurate?
While I have a large bias towards Agile methodologies, as a consultant it’s my responsibility to evaluate what truly is the best solution for a client. I was recently on a project in a marketing organization, and while there certainly were some opportunities for Agile principles to be utilized, a framework like Scrum or Kanban just would not have been possible. Read the Complete Article
Kanban Project Management: the Right Tool for Many Projects
By George Ellis
Ever feel overwhelmed by your task list? Whether it’s your daily work or a simple project, think about Kanban Project Management. A Kanban PM Board is a simple visual management tool for many tasks with few inter-dependencies. For example, you might use Kanban project management for managing ECOs or organizing small customization jobs.
In Kanban PM, each task is listed separately with a sticky note or some electronic equivalent (I sometimes use PowerPoint). The Kanban board is divided into 4 or 5 columns with the tasks starting on the left and flowing to the right. Here’s an example of a personal Kanban management board I use:
Figure 1: Personal Kanban Board
Kanban Project Management KPM) is a pull system. The main action takes place in the middle—”On Deck” and “In Process” in this example. There the maximum size is limited to, say, 3 or 4 tasks. Read the Complete Article
User Stories and Use Cases Go Hand-in-Hand
By Ben Snyder, CEO of Systemation
Whether it’s a software project or a marketing project, all projects have something to deliver. And all projects have users—people who will interact with that end solution, product, service, or other result you deliver. To define the requirements and get agreement on the deliverables, you’ll need the input of these users.
But because users are subject matter experts in their own line of work, they may not always think systematically about how to best tell you what they need. They may struggle to think of all the things that will matter. If you’re the business analyst, that means you have to find creative ways of asking questions to get the information you need.
So, which tool do you choose: a use case or a user story?
The commonality of their names creates some confusion. In the past user stories were thought to be applicable only in the agile development realm. Read the Complete Article
To Squawk or not to Squawk
By Patrick Merg
The daily standup meeting is one of the core concepts of Scrum. In the meeting the team members talk about just three things:
- What I did yesterday
- What am I doing today
- What are my impediments
And that’s it… However, the teams that I see can’t keep it that simple, there is always some banter ( a good sign of team happiness ) and extended discussion on what is going on that may derail the team or another team member. If the discussion goes on for more than a few minutes we table the discussion for right after the standup. While it’s important to keep the standup moving it’s more important not to squash communication.
Who should participate? Anyone who is involved or interested in the project. Who should actually talk? Only the folks directly involved in working on the backlog. The other participants should keep their thoughts to themselves until they get a chance to talk to the Scrum Master away from the team. Read the Complete Article
Planning for a Productive Retrospective – 4 Steps to Better Learning
We’ve all been there before – a project that hasn’t gone so well: over budget, late, not meeting everyone’s expectations (project death marches springs to mind). And of course there are those projects which never actually finish – they simply no longer have anyone working on them.
The executives and senior management now want to forget, or worse still, want some heads to roll.
At the end of the project, the project manager or director (or some enlightened sponsor) may call a Retrospective (or Project Review, Hotwash, Post Implementation Review, etc) to get to the cause of what happened.
To maximize the value of this type of activity to the company, you need to collect both lessons learnt and data (to support the lessons). It also helps protect you when the political ramifications start.
Step 1 – Collect lessons early and often
If you’ve already started your project, or even getting close to finishing, start collecting lessons now! Read the Complete Article
The Scrum PMO
By Russell Whitworth
The challenge is this: How do you make Agile Scrum work in a traditional corporate environment? The problem is simple to state, but the solutions are frustratingly complex.
I am a strong believer in Agile Scrum. I like the theory, and I have plenty of experience of it succeeding in practice (having served as a team member, ScrumMaster, Product Owner and as an agile coach).
Scrum is usually represented something like this:
Figure 1: How Scrum is typically represented
Part of its power is the simplicity of the model. The Product Owner sets the priorities, the ScrumMaster coaches and facilitates the team, and the self-organizing Team gets on with the work. It works very well.
Unfortunately large organizations now throw two huge spanners into the works:
Read the Complete Article
- Governance. Meaning stage gates. Typically there will be a formal and complex corporate hoop to jump through in order to move between project phases (such as from “Feasibility” to “Detailed Design”, or “Alpha” to “Beta”, or “Planning” to “Delivery”).
Planning for a Productive Retrospective – Key Challenges
What are the key challenges to using Retrospectives/PIRs to improve? The challenges are legion are broadly fall under two main themes:
- Duck & cover
Duck and Cover
Read the Complete Article
The Cult of Agile
By Damon Swayn
The original version of this post was much different. I wanted to talk about my feelings towards the cargo cult of those who sell us the Agile Manifesto and talk about software architecture while it seems, at least to me, they probably haven’t written a line of code in many years.
However, after writing a first draft, I feel the need to revise what I think is the real cargo cult in the current age of software development. I did a lot of research, reflected on my experiences, and even talked to a few people.
Agile is a great idea in theory, given that software is a field where estimation is near impossible. The problem with Agile today is that enterprises saw it as a solution to turning software into a profit center instead of a cost center. As much as I’d like to remove myself from thinking in terms of business (I’m an engineer, not an accountant), I want to concede that it does make sense. Read the Complete Article
The Identity Crisis of the Servant Leader!
By Leonor Urena
A Scrum Master Is a Servant Leader
What do you mean by that? I am no one’s servant! I am a facilitator and no longer a project manager. But in no way am I a servant. These were the words of a scrum master many years back. However, I have heard these words and others like this from the majority of scrum masters I coach. I have encountered those who keep the word “servant” and others who prefer “leader”.
The four teams I coached experience this at so many levels. This organization took Project Managers and made them into Scrum Masters. This in itself would not be an issue, if it weren’t for the lack of understanding required to be a scrum master. Not every project manager is suitable to be a scrum master. Yet they still get forced into this role. Read the Complete Article
Scrum Methodology – Agile Software Methodologies
By John Nelson
In our last post, we discussed Agile, its origins, basic concepts, and how it fits into the organization. While we often speak of Agile generically, we have to discuss the development methodologies that share the common philosophical beliefs of Agile.
Scrum is the most prevalent of the Agile methodologies used in software development today, and rightfully so. With Scrum, development is executed via a series of short efforts called sprints. A sprint typically lasts from two to four weeks. The actual duration of each sprint is determined by the customer and the development team, but a sprint should not be too long. We’ll talk more that sprints later.
Scrum Terms and Concepts
Before we begin our discussion of Scrum, we first need to discuss some important terms and concepts associated with Scrum.
Read the Complete Article
- Scrum Team – the Scrum team is generally made up of less than 10 developers, business analysts, testers, etc.