, , ,


, , ,

Waterfall Vs Scrum

Scrum Master Certification

I’m often asked if Scrum is better than Waterfall or Waterfall better than Scrum.

Waterfall advocates that we do a significant amount of design upfront. But its not possible to do it all up upfront. That would be crazy and simply never happened in any traditional project that I was involved it.

Scrum advocated that we should not over designing as the customers/user doesn’t really know what they want. Therefore spending time investigating would be wasted. Let’s just build it and as we build, check with the customer to see if it’s what they want.


Importantly, Scrum is not a series of mini waterfalls where we design for a few days and then build then test the next few days. We should do the design, build and hopefully test at the same time. Removing the upfront design effort and merging it with the build. Chances are, it will take the same amount of effort to design and build but it will be what the customer wants – better quality. And we have maximised the amount of work not-done by not delivering what the customer did not need.

But what about the longer term planning, a lot of the longer term planning goes out the window. But Scrum does not account for the fact that there is still some longer term planning required. For example it may take the supplier 3 months to provide the interface design, or that the training days have to be organised at least 2 months in advance. You are going to have to implement some traditional planning to get this right. Agilest might call this release planning, traditionalists might call it program management. I think they are more or less the same thing – both aim to link organisational strategy to tactics.

Both traditional project management and agile-scrum are trying to tackle the “getting it done” part of the business. This is the tactics for change. However,they approach it in a different way, Traditional Project Management suggests that we can deliver on the tactics by planning, setting the rules and measuring progress. The other option is, agile-scrum and the tactics are achieved by sharing the goals and empowering the team to just getting it done – now.

So what will working better, empowering the team or measuring the activity? You decide based on the complexity of the task and the engagement levels of staff.

Althris provide training in Scrum Master, Certified Product Owner, Agile and Iterative Project Management Methods.

Starting the Agile Journey

Project Management Agile Training

Agile Training

Recently I have had the opportunity to present to students taking Project Management certificates and diploma courses with one of the University programs in Dublin. I was asked to do 1 day on agile out of the 10 or 12 day programme. These are all experienced employees spending considerable time and money on this course.

Each student has a copy of the thick brown PMP (Project Management Professional) manual which I now see has changed from white pages to grey – how apt. At the beginning of the class I get the opportunity to ask them if they have enjoyed reading it. Was it interesting etc?

It generally doesn’t take long for someone to say that it impossible to read or do project manager actually use this stuff etc. This kicks-off my class nicely and I get them to agree that’s it’s “a pile of …”.

Ok I have to roll-back a little as they have spent thousands on this and I better not blow the other 90% of the course out the window yet. And I’m just making the point about the complexity of the approach suggested in the PMP.

After a short discussion on their agile knowledge I head towards the agile manifesto and more importantly the Twelve Principles of Agile Software Development. Two areas cause particular concern.

  • Welcoming change even late in the day
  • Business people and users working together on a daily basis.

They were all concerned about changes going on forever and welcoming more changes then becoming a never ending story. We had a good debate and on this topic I was able get them to agree that a dynamic business would welcome changes and a more conservative business might be better to resist them.  I didn’t need to ask the question “which type of business would you rather work for ?”

I had to take the idea of Business people distracting developers every day on the chin. I couldn’t win this one but again we did agreed that it was vital to have close co-operation especially in a dynamic environment.

Scrum Master Training Dublin Staceys matrix also causes a bit of stir. Interestingly one person was familiar with the “the challenge of complexity” and was keen to point out that Stacey has disowned his own matrix as too many people miss-use it. Ouch – I figured that I could still hold my own on this but best to press on. In particular it was felt that good business analysis can be used get agreement on the requirements reducing some of the complicated work. Additionally good risk management might tackle some of the technology uncertainty.


I didn’t come out of this unscathed but the class got the point. Time for a little light hearted games at this stage.  I used a “document the drawing” vs “describe the drawing” game and this went down really well. We got near total agreement that old-fashioned BRD’s (Business requirements documents) are painful to write and often miss the mark.


Onto a winner now with personas and user stories. By now I’ve started to win them over and it was time to introduce Kanban. Super session and all agreed to implement a personal Kanban board for their exam practice. At this stage I figure I can do no wrong, we agree to break.

The afternoon we looked at Scrum and in particular the Scrum Principles. We hit on the role of the scrum master and servant leadership. We used games to outline “work in progress”, commitment and waste.  The group started to explore how agile would fit into their working environment.

A number of questions arose like

  • But what happens when we don’t have full time teams
  • Most of our project are about integration of suppliers and customers?
  • What about change management
  • How does agile fit with long term planning

By days end we saw some super agile concepts and there was no disagreement that we should really concentrate on getting things done as opposed to over planning everything. Agile is very important for team productivity but scaling was still going to create a management overhead.  Some felt that Agile wasn’t actually project management at all but that it was team management.

PMP may still have a long life but let’s stretch ourselves and be more agile.

Principles behind the Agile Manifesto

Scrum Training

Business Analyst is not the same as a Product Owner

The Product Owner is not the same person as Business Analyst.

The key is in the name, its all about ownership. A Business Analyst collects and analyses requirements which is a major part of a product owner role but there is a lot more to it than analysis.

The product owner roles is to Create Business value, so its not just collecting requirement but it to prioritise them.  The product owner then works with the development team to get the highest priority part of the product produced first.

  • Monitor progress toward a goal (*)

The Product Owner is accountable for the success of the project, that’s a significantly more than most business analyst would say.  Their role is also to create the product vision and create a road map for delivery. It much more akin to a project Manager or I’d even say a project sponsor.

The Product Owner manages the long list of deliverable (called the product backlog). Therefore the roles is more akin to a scope management role.

  • Scope may be clarified and re-negotiated between the Product Owner and Development Team (*)


The Product Owner also defines a definition of done so there is a quality aspect to the role as well. It’s of little value to the customer if the deliverable is not fit for purpose. They are not the only person doing a quality role the development team has a roles to play.

  • This Increment is useable, so a Product Owner may choose to immediately release it.(*)

The Product owner is responsible for communication. Particularly to stakeholder and to enable the appropriate level of communication between stakeholders and the development team.

  • Ensure that the product backlog is visible, transparent and clear to all (*)

If the product Owners Role is to create Business Value then they must also ensure that the development has the appropriate resources to get the value. This element of the roles may be shared with someone like the Scrum Master who is trying to remove impediments. But to me it suggests the Product Owner is responsible for cost management.

The Product will document requirements, probably in the form of user stories but the role is not just Business analysis.  The role also takes over some of the Project manager’s role and also some of the Sponsor’s role.

(*) Taken for the scrum guide

Althris provide Scrum Master Training Dublin

Planning and Execution of Test Cases During Agile Development Iterations

Scrum Testing Product Owner


During the software development process it is vital to establish a robust process of software quality assurance, even if you are developing using an Agile development methodology.

It is important to mention that Agile development should not be confused with development without a defined quality management software. It is strongly recommended that the tasks of creating test cases and performing automated tests be planned for each development iteration.

In addition, having a test-focused person is a key to the quality of software development during the Agile iterations.

Agile Planning and Quality Assurance Tasks

The Agile iteration planning process allocates at least one resource for testing activities, and does not involve this resource in development activities within the iteration. This process is important to avoid poor quality testing.

Within a development team of five people, having at least one person focused on these tests tasks will greatly help to ensure the quality of the software. In this case we are talking about functional tests (black-box testing) planned and written through test cases. However, we must not forget that the unit tests (white-box testing) are the responsibility of the development team, and the tasks of developing these unit tests must be estimated together with the backlog items.

The advantage of include planning and execution quality assurance tasks even in an Agile software development cycle is the concern of the development team in delivering quality software to those responsible for running the tests. It is amazing how the simple fact there is a person planning and thinking about software testing already increases the quality of the software.

Here are some tests tasks that can be executed during a development iteration:

  • Creating a test-planning;
  • Creating the detailed test cases for each user story or backlog item;
  • Preparing test environments required for system tests;
  • Preparing test data: getting real data from production or simulation.

In addition the tests can be automated, so the tasks below can be included:

  • Automating unit tests;
  • Automating functional tests;
  • Writing mocks, test drivers, data simulators, test frameworks.

Scrum Master Dublin

Tools for planning and running tests

It is not the purpose of this article to present test tools. However, it is important for the agility of the software development process to look for tools to automate the execution of the tests as well as documenting the test plans and the test cases.

Remember that tests can be re-used in future development iterations, so it is very important to define a centralised method and tool to manage the test plans and test cases. An efficient test management tool will help you with the agility and quality of your software.

The following are some suggestions for test tools:

  • qTest
  • PractiTest
  • Test Collab
  • TestFLO for Jira
  • XQual
  • TestCaseLab
  • Microsoft Test Manager (Test planning and automation)
  • Microsoft Team Services (Test cases)
  • Selenium (Automation of functional tests for Web applications)
  • TestRail

Agile Estimation: Approaches

Planning Poker

Agile Estimation: Approaches

The software development process, with its constant uncertainties and frequent changes, together with the difficulty in getting users to articulate their requirements, has long been a headache for project managers.

Agile development processes still bring with them some of these headaches, but we can simplify the estimation process. I have listed some of the approaches below.

Poker Planning Games

Planning Poker

Planning Poker

Planning Poker is a technique used to estimate the relative size of tasks, or the effort required to complete them, in software development. A development team estimates using a deck of cards that are usually a Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, … ) to indicate the difficult of the task. You can easily replicate this by asking the team to make their own cards. When starting off in Agile, sometimes teams equate this to the number of hours required to perform the estimated task – though this is probably not the best way to do it.

The estimates occur as follows:

An item is selected for discussion.

  • Each team member chooses a card that most reflects the “size” of the selected story (or task). This decision is based on the knowledge and experience of each member of the team.
  • All members show their cards at the same time so that there are no changes of mind after each member has seen the other hands.
  • In most cases we will have cards with different values. The divergences, and the reason for the differences in the estimates, is discussed. Large divergence suggests a lack of information, in which case more negotiation/discussion must occur in order to get agreement on the estimation.
  • The story estimation ends when the cards’ values converge to a value agreed by shared consensus of the team.

Agile Estimation using the Fibonacci sequence

Consider the sequence of numbers 1, 2, 3, 5, 8, 13, 21, ….

Each number is the sum of the two previous numbers. In some cases, the numbers are rounded up or down to the nearest 5 or 10. Often a 0 and a 1/2 are also added. 0 (zero) represents a story that requires no appreciable effort to develop; for example, if another story already being completed will be used to end this story.

Generally, the question mark is used to indicate that a team member does not have enough knowledge of the story to estimate it, and thus requires more discussion and greater detail about the story.

The symbol of infinity is used to indicate that a story is too large to estimate, more like an epic, and so needs to be broken down into smaller stories.

The idea here is that the team should really develop their own technique for building out estimates. Time may not be the best measure, as the team should be trying to get more efficient in each subsequent sprint. The non-linear nature of the Fibonacci sequence makes it harder to sit on the fence with in-between estimates.

Estimate user stories using T-shirt sizes

T shirt sizing


There are several other ways of estimating stories, another of which is T-shirt sizing. In this type of estimation, stories can be small, medium, large, or XL. What exactly these sizes mean depends on the team. In addition to the terminology being familiar and easy to use, even by non-technical people, this works really well on teams with very short iterations.






Estimating software delivery times really is an art. The accuracy of the estimate depends greatly on each team, as well as the level of detail available for the estimate. The most important thing is for each team to evolve, always seeking to increase the accuracy behind the estimates.

In addition, estimates combined with good retrospectives can help identify parts of a system that need refactoring. For example, if stories fall behind, or are often labelled as difficult, you can investigate what these stories have in common, and seek solutions that can mitigate those problems.

Of course there are many agilest that advocate no estimates at all


How do you eat an Elephant

How do you Eat an Elephant

So we have heard the saying, How do you eat an Elephant – One Bite at a Time. Well that’s not how project managers eat elephants – Project manager share the elephant – divide it up and find the right people to do the eating.

Why?  There are a number of reason why

The Elephant will be well gone off before we progress any distance. Project management need to create a sense of urgency and if the goal is to get the elephant eaten then we have to share.

We will be sick of elephants. We need to give ourselves little goals otherwise we will be sick of the tedious task of just eating the same thing.



To share we first must break the Elephant down into manageable pieces. Project manager call this the work breakdown structure. Once we have identified the manageable pieces we find the right person to take on this smaller task. In-fact the The project manager puts together a team of people to work on the job simultaneously thereby getting the elephant eaten as quickly.

If it all goes well,  chances are the project manager didn’t actually eat any elephant, he share everything.

, , ,

To PMO or not to PMO


Emotional Intelligence for Project Managers

emotional intelligence Project Status Report

Five Results from Emotional Upgrade


The people side of project management (or any management role) is the hard bit. We have to effect action and change while being conscious that we cant make people do things. We got to get them to take action for their own reasons.

Being emotionally aware can really help us understand both ourselves and therefore understand what makes others tick.

So what is emotional intelligence: Emotional Intelligence can be defined as an understanding one’s own feelings, the feelings of others, and managing the emotions to enhance growth and living. The major domains of emotional intelligence are knowing your emotions, understanding these emotions, motivating yourself, recognizing the emotions of others, and establishing a strong balanced relationship with them.

So get yourself an Emotional upgrade.  First with self-awareness (the understanding of ones strengths, limits and confidence). This evolves into social emotions (sensing others emotions), helping to develop these emotions and on the long run building lasting bonds with people.

Five results of emotional upgrade include:

  1. Self- confidence: After having read and studied your own personal emotions, you are confident that you can bring them under subjection at every time, this inflicts a level of self-control and a sound sense of self-worth and capabilities.
  2. Adaptability and influence: This means you’re sensitive and flexible enough to maneuver into people’s emotions, feelings and at times their decisions thereby resulting into a striking level of positive commitment in their activities and regulars. You have studied them enough to relate with them at their highs and lows.
  3. Relationship management: Conflict management, being a change catalyst, building bonds, teamwork, and collaboration with others is achievable when there is a conscious review of ones emotions.
  4. Social competence: This expansion of awareness and empathy of the environment increases communication and the ability to persuade, and develop opportunities to strengthen the growth of others.
  5. Leadership: Here, your team is willing to allow you lead and are willing to work with you to meet set goals because you inspire them to achieve the collective vision.

Emotional intelligence may have gone off your radar but I suggest you give it another looks.

Sign-up to request 25 steps to improving your emotional intelligence .