Select Page

Categories

The Great Delivery Debate

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

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:

Personal Kanban Board

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

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

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

Planning for a Productive Retrospective – 4 Steps to Better Learning
By Zenkara

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

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).

The challenge

Scrum is usually represented something like this:

Typical Scrum representation

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:

  1. 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”).
Read the Complete Article

Planning for a Productive Retrospective – Key Challenges

Planning for a Productive Retrospective – Key Challenges
By Zenkara

What are the key challenges to using Retrospectives/PIRs to improve? The challenges are legion are broadly fall under two main themes:

  • Duck & cover
  • Technical/procedural

Duck and Cover

  • A general reluctance to do it – “We don’t want to do it because the project didn’t deliver, went poorly, cost too much, and we’ve heard heads need to roll. This can be the result of a toxic culture and can only be resolved by sponsors, execs and senior managers communicating and promoting the value of Lessons Learned – and not laying blame as the first resort.
  • “We don’t have time to do it” – this often has the same cause as a) but can be overcome through some prep work prior to the Retrospective session, and then shortening the session to an hour or two. In any case Retrospectives/PIRs are rarely effective when held over two days.

Read the Complete Article

The Cult of Agile

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!

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

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.

  • Scrum Team – the Scrum team is generally made up of less than 10 developers, business analysts, testers, etc.
Read the Complete Article

Recommended PM App

Recommended PM App

Categories