The Agile Doctor?

Many different types of Agile consulting firms do some sort of Agile assessment with their clients if the need is there. Well no longer. You can get an Agile check-up online. With Dr. Agile!

I wasn’t sure whether this was a joke or not when I came across the website, it smelt of a bad infomercial right off the bat. Grainy graphics, a funny looking dude with post-its all over him. What would you expect?

Well I did take the assessment. Wasn’t fully convinced that it was all too helpful though. Many of the questions had me wondering whether the assessment was for Agile-noobs or for experienced Agilists. Many of the questions assumed you already knew the lingo and certain “Agile” words.

One thing’s for certain, though. If you know enough about Agile, this quick 3 minute assessment may just help you… do… something with the information. Not sure yet.

Here is an example assessment after I went through it:

Continue reading “The Agile Doctor?”

IT Turf Wars? Agile Can Help

The guys over at InfoWorld put together an article on the Top 4 Information Technology Turf Wars. Whether it is Security vs. The World, Operations vs. Development, Admins vs. Other Admins, or IT Management vs. The Staff, it seemed that they hadn’t fully thought through some of the ways that some facets of Agile could help alleviate some of the frustration.

On Security vs. The World:

“When someone comes to the security people and says, ‘I want to do this,’ security’s default answer is to say no…”

Agile can help by bringing in the security personnel into the process earlier. While working through stories or grooming the backlog, it can help to have a security representative be part of the tasking-process. This can help in that the security dude can give technical and potentially architectural guidance around requirements.

On Operations vs. Development:

“The classic conflict is that IT is very often just managed as a cost center… They believe their job is to figure out how to do more with less… The operations side saw its job as managing costs, while the developers saw their job as managing quality…”

Agile can help by bringing QUALITY into the mix. Since so much of IT resources are focused on fixing and working through environmental issues and maintenance, Agile can help by defining “done” with quality baked in. As quality controls are built into the development process, less and less will break and operations will see development as something more than just managing a cost center.

On Admins vs. Other Admins:

“The classic scenario: A sys admin departs on bad terms and decides to wreak revenge… We’ve had to deal with admins who’ve abused their privileges maybe a couple of dozen times. For 99.999 percent of admins, this is never the case. But when we do hear about a rogue administrator gone wild, the danger is to say admins are going to run amok and steal things from the company. It breeds a culture of mistrust from management to security to IT. It’s counterproductive.”

Agile can help by bringing in two things: Cross-pollination of skills and knowledge through paired programming and (pair) administration, and creating an environment of transparency and accountability to those system admins. There should almost never be one single point of failure. How many horror stories have been told about the guy who got hit by the bus and now nothing can get done? Or is it more politically correct to say that he “won the lotto?” Agile is about transparency and disclosure into those things previously hidden. Utilize it for goodness’ sake!

On IT Management vs. The Staff:

“The biggest conflict is between IT management and IT staff… For some reason, the companies I’ve worked for seem to hire or promote people who are not technologically literate.”

Agile can help through inspection and adaption of processes and procedures. As the stakeholders, Product Owners, and management personnel learn more about what is going on with development, they will not only learn, but also be a more informed party during the development cycle. Bring your IT people into the fray. Let them into the development process. Over time, they’ll learn, and who knows, our know-it-all-senior-developer might learn a bit more about how the business runs as well.

[HT: InfoWorld]

Ruhroh! Challenges and Changes for Scrum Alliance Again

The Scrum Alliance just announced that they are parting ways with Donna Farmer, whom many saw as the beacon that would help lead the Scrum Alliance to greater glory with the 2011 Strategic Plan. Ruhroh! Looks like we’re headed into more challenging territory.

Excerpt below:

The Scrum Alliance Board of Directors has parted ways with former Managing Director Donna Farmer. The Scrum Alliance appreciates the work Donna accomplished during her time with us and we wish her all the best.

This definitely will make things interesting for the SA in 2011. We’ll stay tuned to see how things turn out!

[VIA: Scrum Alliance]

Top 10 Essential Product Owner Characteristics

We’ve written a bit about the product owner before:

  1. Product Owner Top 10 Backlog Tips
  2. 4 Questions a Product Owner Needs to Answer – In order to give good direction about a product
  3. 7 Product Owner Responsibilities and 4 Product Owner Artifacts
  4. Product Owners are VIPs – The PO tells us what to build!

Now we’re going to give you…

Top 10 Product Owner Qualities and Characteristics

  1. Engaged leadership – The best Product Owners are engaged in the entire process. A dis-engaged PO finds himself outside of the process quickly. An engaged product owner is a natural leader. He finds himself leading a team through his decisions and makes it apparent to the team that he is committed to not only the process, but the final product as well.
  2. Available within reason – The best Product Owners are available to the team, but within reason. There is something about co-locating oneself within the team so they have zero walls to climb in order to receive feedback and potentially daily guidance. The availability can come at a cost though, with an immature team who is lacking the accountability and responsibility of building the needed project. Be tactful here and give a healthy balance between availability and baby-sitting a development team. Sometimes helping them help themselves can create a partnership between team and PO that reeks of productivity!
  3. Informed about the product – The best Product Owners know the product inside and out. Noobs need not apply here. Subject matter experts on not only the product but also the market will find themselves the best prepared for giving updated feedback and guidance to a development team. Understanding beyond the product can help here as well, but core to the Product Owner role is their ability to intimately know and understand the product or product set they are helping a development team build. Continue reading “Top 10 Essential Product Owner Characteristics”

The UK Govt Manages Your Pensions Using Agile

The Department for Work and Pensions in the UK is taking your money seriously. So seriously that they’re going to be managing the software side using Agile methodologies.

“The Department for Work and Pensions (DWP) faces constant pressure to provide its end-users and partners with customised, high quality, working software applications on time and to budget…[aren’t we all]… “Agile is already delivering for us, and it is our intention not to use the old style of project management for new projects in the future. “That does not mean to say that all of what was done in the past was wrong – the old way, provided it was supported by effective collaboration worked and did deliver, but not as efficiently.”

This sounds good to us, but it seems that not everyone over there in the UK are sold 100% on Agile:

“But whether more lightweight, incremental agile alternatives that place greater emphasis on collaboration between teams of developers and end user interaction are the best way forward in every case is not certain either… It is not necessarily the fault of IT but it begins with the client and it is incumbent on me and anyone else in my position to be really clear about what the client wants and how they want to go about achieving it, and collaboration is key to this.”

Taking small incremental steps will help. It’s good to know that other government agencies (Veterans Affairs) around the world are taking notice of Agile and utilizing it (Obama told us to use Agile anyway). Could it be said that the governments are finally doing something right?

Maybe we’re just biased.

[HT: Computing UK]

Week Retrospective 25 – Scrum Backlog Tips and 3 Types of Scrum

[blackbirdpie id=”50895374617030656″]

[blackbirdpie id=”50181755495399424″]

Kanban Elevator Pitch – Help Craft It

Kanban is a way to incrementally and continually improve your approach to meeting your goals, by understanding the situation clearly, identifying the real challenges and testing out your chosen options for resolving those challenges.” – John Stevenson

Here is a great starting point by John Stevenson.

I’d like to open up the comments to help craft the perfect kanban elevator pitch.

What would you say?

[HT: Lean Agile Machine]

3 Scrum Types – Your Flavor of Scrum?

Yusuf Arslan put together a pretty long piece on what he finds to be the definitive 3 Scrum characters that you could be: Social Scrum, Pragmatic Scrum, or Purist Scrum. Where do you fit?

Social Scrum:

The art of telling people you do Scrum to avoid the more difficult issues.

  • Pros: Easy and fun (no conflicts), Better motivation, Potential for more adaption
  • Cons: Nobody accountable for team results, Can result in micro management, No performance improvement

Pragmatic Scrum:

The art of doing what works right now but not making long term improvements.

  • Pros: Quick productivity improvements, Better communication, Fast start
  • Cons: No organizational improvements, Can’t determine the capacity, After the quick wins it can become worse.

Purist Scrum:

Doing Scrum by the Ken Schwaber book, but not adjusting for per-project needs.

  • Pros: Self managing, Innovative, No overhead costs
  • Cons: Architecture and infrastructure, Need a change of engineering practices, Doesn’t provide any guideline on a lot of (hard) questions, time-consuming, Potential for conflict, Costly to build

So is this it? Is there more?

[HT: Yusuf Arslan]

Department of Defense (DoD) is #1 using Open Source for Govt

“Open Source for America (OSFA) recently published a report card on open technology and open government across several U.S. federal government departments and agencies. The results: One-third of agencies received a passing grade. OSFA, a coalition launched in July 2009 to encourage U.S. federal government support of and participation in open source projects and technologies, worked with government departments and agencies to develop the methodology and rate each group.”

Who’s the winner? The Department of Defense. It seems that the Department of Defense (DoD) achieved the highest ranking, with a score of 23 out of a possible 28, and stands out in the report card for several reasons:

  1. First, the DoD has documented policies for selecting and acquiring what the report identifies as open technologies.
  2. Second, the DoD provides guidance for employees wanting to participate in open source projects.

“IT decision makers are encouraged to follow in the DoD’s example and set a policy, along with related processes and safeguards, for employees to contribute to open source projects…Doing so will keep your developers happy and help encourage innovation, within and outside of your company — a win-win-win strategy.”

I believe open source is definitively “Agile.”

What say you?

[HT: InfoWorld]

[Product Owner] – Top 10 Backlog Tips

Lists rock. They’re even better when someone has put together an awesome list for public consumption. Upon thinking about how to better use your product backlog as a Product Owner, consider the following helpful guidelines [distilled for a quicker read].

Top Ten Backlog Tips

  1. One product at a time – Derive your product backlog from the product vision or the product roadmap.
  2. Detailed – Make your product backlog as detailed as possible.
  3. Be structured – Group similar items items into themes.
  4. Visible – Put your backlog up on the wall.
  5. Focused backlog – Start with many, but have the courage to weed out other items over time.
  6. Capture functional requirements – Start with large, coarse-grained stories and progressively decompose them over time into detailed ones utilizing customer feedback.
  7. Start with risky stories first – Use risk/uncertainty, dependencies and releasability to decide how soon an item should be implemented. Addressing risky items early on allows you to fail fast.
  8. Manage global nonfunctional requirements carefully – Describe them precisely upfront. Capture operational qualities such as performance, robustness and interoperability as constraints; describe usability requirements visually, for instance in form of sketches, mock-ups, and screen shots.
  9. Housekeeping – Groom your product backlog regularly and collaboratively. Run weekly grooming workshops with the team to ensure that your backlog is in good shape. Involve stakeholders including customers and users as appropriate.
  10. Be ready – Make sure the top items are always “ready:” clear, feasible, and testable. This allows the items to flow into the sprint and facilitates a firm commitment.

[VIA: Roman Pichler]

Best Way to Set Up Your Agile Office – Is an Open Office Right?

[We wrote about co-located and Agile office space before here.]

Computerworld recently spoke to IT managers at a range of companies, from giants like Google to small consultancies, to get a sense of which office layouts are better for which types of high-tech workers and which are not.

Here’s a recap of what they found about IT’s likes and dislikes and why office layout is not a decision to make lightly.

“Every IT worker I have managed has jumped at the chance to move from a cubicle to an office when given the opportunity. And yet these workers still want their offices to be located close together, so they can easily bounce ideas off people who understand what they’re talking about. When they have a problem, they can quickly explain it to someone to get an answer, she says. But they also like to be able to withdraw.” – Manager (who wished to not be named)

“There’s a big difference between the needs of a network administrator and a help-desk staffer… That’s because some IT jobs require large blocks of uninterrupted time for concentration, while others involve reacting to situations as they arise. If a network administrator is interrupted midtask, it could take him 45 minutes to figure out where he was in his project, and if you’re constantly working in 45-minute [increments], you’re never going to get there.” – Shaun Walter, Sr. Unix Sys Admin of Ally Financial

Continue reading “Best Way to Set Up Your Agile Office – Is an Open Office Right?”

Daily Scrum Standup Meetings

Is this true? Are your teams more productive because you have standups? I’ve found that some teams really dislike the daily standup because:

  1. They already communicate very well
  2. They collaborate and escalate issues immediately to the ScrumMaster
  3. They receive all their needed guidance from a Product Owner whenever they want
  4. They don’t need to write on stickies on a wallboard
  5. They don’t feel the need to use a burndown chart

So, what are your thoughts? Still worth having? Or are these teams missing something?

Week Retrospective 24 – The Perfect ScrumMaster and User Stories

Agile Modeling and UML – The Truth is You Already Do UML

Terry Quatrani, a Rational evangelist at IBM reminds us that Agile and modeling (UML) aren’t diametrically opposed. Actually they play very well together.

“I am following an Agile process so modeling is not important.”

A phrase that Terry hears often. Her response: “That is simply not true.” Her reasoning?

“Even if you are following an agile process, you will do some degree of modeling – you just won’t do it as much as you would if you were following a traditional process. Also, the degree of formality will probably be different… A lack of formality in Agile UML doesn’t mean that you’re not modeling – it just means that you’re likely focusing on getting the benefits of modeling without the drawbacks of extraneous documents.”

To Terry, no matter what type of process you follow, Agile or not, you still need to do some requirements of some sort. If you’re using an Agile process, your requirements are often captured in the form of customer tests and user stories.

Continue reading “Agile Modeling and UML – The Truth is You Already Do UML”

[Survey] – Portfolio Management for Agile IT – And the Winner is Waterfall


  • 88% believe that the volume of projects developed using the Agile methodology will grow.
  • 59% of European organisations use/will use a combination of Agile development and waterfall.
  • 5% of European organisations intend solely to use the Agile methodology and 12% intend only to use waterfall.
  • 43% of European organisations believe that the importance of Agile development will grow in the next few years. By contrast, 56% believe that Agile development will become more important but waterfall will continue to play a significant role in most projects.
  • A quarter of the audience is using Agile development in 20% their projects.
  • The challenges inhibiting organisations from implementing an Agile approach include cultural change, control, and lack of executive buy-in.
  • Agile projects are managed via a variety of disparate systems.

The research provides conclusive proof that more and more organisations are choosing to plan and execute their portfolio of projects using Agile methodologies in some form—with a majority of organisations increasingly using a blend of both Agile development and waterfall techniques. This new approach is being fuelled in part by consumers of cloud services, who demand the right balance of governance, rapid delivery, and fast response to requests for enhancements and new services. The survey also reveals that the majority of organisations will continue to use a blend of both Agile and waterfall development, with the trend towards Agile development in the next few years.

[Agile Guide] – Estimating User Stories in Agile

As a developer, we have the toughest role throughout the project lifecycle: Estimating our work. The business (typically) puts so much at stake onto the developer for elaboration and understanding about the time and schedule of a project. It’s a tough life for a developer.

But fear not! There are resources to help you estimate your stories.

One great article we recently found was by Nicole Rauch, she states when when estimating a story you need to take into account several things:

  • Complexity: Consider the size of the story.
  • Risk: Consider the teams inexperience with developing this story.
  • Implementation: Consider the implementation factors.
  • Deployment: Consider the deployment requirements.
  • Interdependencies: Consider other outside issues.

We would add that developers should begin (over time) to develop a baseline for estimating sizes of stories. Use examples of past stories that can help developers understand relative sizes. Ask questions like: “How does this story compare to X-story we did before? Bigger or smaller?”

Now, the question really is whether you use points or hours for estimation. Mike Cohn suggests to use points for product backlogs, and hours for tasks.

Bottom line? Agile estimation is an art form that grows better over time. As your team matures and developers a solid baseline for estimating work it can produce a consistant cadence or velocity that is (somewhat) predictable for the long run, but not great at estimating short durations.

Find out more:

Agile Estimation and Planning- Peter Saddington

[HT: pBoop]

[Tool Review] – Tom’s Planner – Making Gantt Charts Pretty

[We review Agile tools. Have you seen our Agile tools list?]

Are you an Agile Project Manager or Scrum Master Project Manager? Read: Standard Project Manager? Well, if you have a client that still needs Gantt charts to see schedules, look no further. This tool is a really easy gantt chart maker, all on the cloud.

“Tom’s Planner is Gantt chart software that allows anyone to create, collaborate and share Gantt Charts online with drag and drop simplicity. It’s web based, extremely intuitive and easy-to-use.” – Tom’s Planner

[Enter]: Tom’s PlannerReally pretty online gantt chart maker

So why are we reviewing this tool? It’s not exactly a standard Agile tool and many people would say that making a Gantt chart isn’t Agile at all. I would disagree. These type of scheduling charts still have their place in business. So let’s give it a run.

Continue reading “[Tool Review] – Tom’s Planner – Making Gantt Charts Pretty”

The Perfect ScrumMaster Job Description

[Go here if you’re looking for ScrumMaster Interview Questions *POPULAR POST*]

I was commissioned by a client to put together a ScrumMaster character profile for helping them choose good great ScrumMasters to join their team. Please do notice that no where in this job description is certification. I believe that a good great ScrumMaster is all about the character.

A high performing team, an active and involved Product Owner, and business support can help a new ScrumMaster do their job very well. Character, however, isn’t taught, it’s grown.

Top 10 Personal Skills for a ScrumMaster:

  1. Servant Leader – Must be able to garner respect from his/her team and be willing to get their hands dirty to get the job done
  2. Communicative and social – Must be able to communicate well with teams
  3. Facilitative – Must be able to lead and demonstrate value-add principles to a team
  4. Assertive – Must be able to ensure Agile/Scrum concepts and principles are adhered to, must be able to be a voice of reason and authority, make the tough calls.
  5. Situationally Aware – Must be the first to notice differences and issues as they arise and elevate them to management
  6. Enthusiastic – Must be high-energy
  7. Continual improvement – Must continually be growing ones craft learning new tools and techniques to manage oneself and a team
  8. Conflict resolution – Must be able to facilitate discussion and facilitate alternatives or different approaches
  9. Attitude of empowerment – Must be able to lead a team to self-organization
  10. Attitude of transparency – Must desire to bring disclosure and transparency to the business about development and grow business trust

Technical Skills:

  1. Understand basic fundamentals of iterative development
  2. Understand other processes and methodologies and can speak intelligently about them and leverage other techniques to provide value to a team/enterprise
  3. Understand basic fundamentals of software development processes and procedures
  4. Understand the value of commitments to delivery made by a development team
  5. Understand incremental delivery and the value of metrics
  6. Understand backlog tracking, burndown metrics, velocity, and task definition
  7. Familiarity with common Agile practices, service-oriented environments, and better development practices

*The above technical skills are nice-to-have, but not necessarily required!


Week Retrospective 23 – Agile Hippies and The Death of the Iteration


[blackbirdpie id=”46500699130966016″]


[blackbirdpie id=”45037293131669504″]

Agile and Fixed-Scope Projects – It Can Be Done!

All projects have constraints. Whether it be the cost, the scope, or the time. We hear a lot about how Agile doesn’t work well with fixed-scope projects. Hey man! That’s just not true!

One thing we have to make sure, first is whether you’re talking about a project or a product. We’ve all heard that Agile software development wasn’t made for projects, but as a product management approach. What gives? Agile works in all facets of life, even projects!

Joseph Flahiff wrote about this in SearchCIO recently and we would agree with his sentiments:

“Some people will tell you that scope is the one thing that is never managed on an Agile project, but is left flexible. In my experience, this point of view just sells Agile short.”

So, which projects benefit from a fixed-scope approach?

Continue reading “Agile and Fixed-Scope Projects – It Can Be Done!”

[Tip] – Agile User Stories – Specific Role Names (Personas)

Quick tip for today from Michael Bosch:

Make sure you write down a [specific] role when you write a story, also called a “persona.”

Make your user story more valuable to a reader by giving more specifics about the user.

For example:

As a [customer], I want to [save my session], so that I can [return and complete the form later].

A better way:

As a [returning user / un-registered user / super-user / admin / etc.]… I want to… So that…

“This level of specificity could provide valuable insight into the intended audience and how best to implement the feature.” – Michael Bosch

Thanks Mike!

[HT: MikeBosch]

The [Iteration] is Dead

Erik Huddleston recently wrote a provocative post on the Death of the Iteration.

He states that we mainly adopted iterations based on three (3) primary drivers:

  1. Cadence –Iterations represent a rhythm to the development process.  Rhythm through repeated routine is a critical driver of productivity and consistency of output in any repetitive task.
  2. Forcing Function – The iteration, with its short duration of typically a week to a month, serves as a forcing function to drive features to conclusion.  This forcing function also ensures that features are small and implementable in a reasonable amount of time.
  3. Synchronization – Most importantly, iterations form a natural synchronization point for stakeholders both upstream and downstream to the development process.  Small iterations reduce the risk of defects and environmental instability and shrink remediation times for defects by shortening the time that between when a change is introduced and when it can be put into a production or simulated production environment.

So why do iterations need to be laid to rest?

Continue reading “The [Iteration] is Dead”

Hippies Love Agile Software Development

Nick Oostvogels wrote a post that just made us #LOL in our seats. We’re not quite sure where the idea came from that hippies and beatniks cannot do real Agile, but we’re sure they can. Maybe it’s more like an Agile Cult.

Regardless, Nick puts together a quick-and-dirty defense for five (5) foundations of common-day-Agile and why they are valuable for the business.

1. Daily stand-up

  • Impression:  15 minutes of jabbering about details and drinking coffee.
  • Reality:  A timeboxed meeting requires great discipline from all attendees.

2. Retrospectives

  • Impression:  A chance for the team to complain about management.
  • Reality: By focusing on improvement, these sessions can be creative and energizing finding new opportunities to work better in the future.

3. Planning poker

  • Impression:  Childish game that provides food for discussion about scope.
  • Reality:  Studies have proven that estimates which are made by the people ending up doing the job, are more accurate.  The benefit of estimating in group is that your personal understanding gets enriched by each persons view of the task at hand.

Continue reading “Hippies Love Agile Software Development”

Week Retrospective 22 – Writing Better User Stories




Agile Software Development Doesn’t Create Secure Software

We recently came across a fun book. A book that basically tells us why most Agile software development projects do not include security in their processes and that most software built in an Agile-fashion are not secure.

Wake up call anyone?

Below is some of the abstract from the book:

“In this article, the authors contrast the results of a series of interviews with agile software development organizations with a case study of a distributed agile development effort, focusing on how information security is taken care of in an agile context. The interviews indicate that small and medium-sized agile software development organizations do not use any particular methodology to achieve security goals, even when their software is web-facing and potential targets of attack. This case study confirms that even in cases where security is an articulated requirement, and where security design is fed as input to the implementation team, there is no guarantee that the end result meets the security objectives.”

The authors contend that security must be built as an intrinsic software property and emphasize the need for security awareness throughout the whole software development lifecycle. This paper suggests two extensions to agile methodologies that may contribute to ensuring focus on security during the complete lifecycle.

Worth a read for $30? Yep. I bought a copy. I’ll update this post as I finish it and let y’all know.

[HT: IGI-Global]