Learn all about scrum & agile programming

Scrum

Agile Assessment

Members of my company‘s consulting team recently engaged in an Agile Assessment at a medium-sized financial organization. I thought the approach was interesting, and it might be useful to share it here.

The team went on site to conduct interviews and observations in 5 areas –

• Value delivery
• Agile engineering
• Project Management
• Product management
• Environment and Organizational Culture

In addition, the investigation took input on the demographics of the individual project being examined, the stakeholders involved and the competitive/regulatory environment in which the organization as a whole operates. Understanding the context in which an organization operates is crucial to understanding the optimal level of Agility, and thus, the plan of action. Understanding the goals of the organization is particularly important. Not every axis needs to be top-ranked to achieve the company’s goals. In fact, on this particular assessment we found that only one needed urgent attention – Project Management. More on this later.

Introduction to Scrum Video

A colleague of mine, Michael James, just posted his Introduction to Scrum video on YouTube I think is the right length and depth for an overview – it’s not so short as to be trite (or worse, incorrect), but it’s not an exhaustive examination of Scrum either. This video is good prep for people who are planning to enter a CSM class and don’t want to go in cold. It is also good for stakeholders around the company who want an understanding of Scrum so that they can work better with their development teams.

I’d be very interested in hearing your views of this video.

Interest on technical debt

Somewhat random thought: Technical debt consists of those things that you postpone doing that you know must be done. As time goes on, it becomes more expensive to address those thing. I like the idea of extending that “debt” metaphor to include “interest”. With that in mind, one can see that technical debt is not necessarily all bad, just like incurring debt to make a business investment may be a new wise decision. There are often valid and justifiable reasons for incurring technical debt. As long as teams incurring that debt know what they are doing and have the means to pay it off in the future, then it is justifiable and desirable.

Visibility is the key.

Online Scrum Training

Michael James is a well respected and widely published Certified Scrum Trainer that I work with. He has created a very useful and informative series of videos on Scrum. The first of these are now posted on YouTube. See it here.

I’ll post up the subsequent videos as they are made available.

Strategic Vision and Scrum

When organizations adopt an agile approach to development like Scrum there is so much focus on the iterative nature of agile development that long range vision and strategic product design can get lost. Check out this upcoming webinar by Jimi Fosdick. In it, he talks about the need to include long term product vision, coherent user experience and User Centered design and architecture along with specific best practices for achieving a coherent product that delights users.

Topics will include:

> Product Vision and approaches to crafting a compelling overall vision for products
> User-Centered/Value-Driven design and approaches to incorporating user experience (UX) and software architecture early in the development process
> Explanation of the pitfalls of a lack of vision and so-called “hybrid” models for incorporating UX and architecture into Scrum Projects

You can sign up here:

Planning for Technical Debt

For systems with a lot of technical debt problems, it’s not uncommon to spend 20-50% of on-going development time toward repaying that debt. Obviously that has an impact on project schedules. The risk, however, of ignoring these problems is sudden and impactful failures, perhaps in production. Work focused on technical debt needs to be prioritized and part of the project plan. By chipping away at technical debt in a long-term fashion, it is possible to reduce the risk of catastrophic production failures, improve the morale of developers, and ultimately speed up development on legacy systems.

The decision to incur technical debt should be a conscious one.. However, unrealistic time tables and feature pressure often force a team to cut corners. There may be valid reasons to take technical shortcuts, but that decision should reside with the PM/PO, not the engineers building the product. Decisions about product quality should always sit with the individual(s) making scope, schedule, and resource decisions.

My company has written a white paper on this which you can review at here .

Building the Product Backlog

Building and maintaining a Product Backlog can be a time-consuming effort. Though the Product Owner has final say in the prioritization, a good product backlog is a result of a combined effort of the entire team – Product Owner, Scrum team, ScrumMaster and stakeholders.

One expert in this area is CollabNet Certified Scrum Trainer Angela Druckman. Ms. Druckman will be hosting a webinar focusing on techniques and ideas for improving the overall effectiveness of backlog management.

The webinar will be held on Monday October 27, 2011 at 11:00 am pacific time. You can register at the CollabNet website www.collab.net – www.collab.net

Is the Whole Greater than the Sum of Its Parts – Or Does it Lead to Incompetence?

How can a group of people – all of whom are individually capable and reasonable, form a team that is incompetent and unreasonable?  This is an intriguing topic being discussed on the Scrum Alliance Google group site.    Normally when we think of teams we think of a “greater collective intelligence” or how the “whole is greater than the sum of its parts”.   However, sometimes teams can also be “incompetent”, “unreasonable” or dysfunctional.  How can that be if the individuals within the team are not that way?  One view being expressed by the person that raised the topic is that team problems are often caused by people being afraid to open up about uncomfortable truths.  During meetings they will nod their heads in agreement, but in private, they fume.    Is this because they do not know how to voice their disagreement in a non-confrontational manner?  Or is it because team members do not have transparency into the complete status of the project and what other team members are doing and therefore their decisions may be biased due to lack of information and empathy?  Scrum tools and agile games are great because they address these “people issues”.     Using Scrum helps to create an environment of transparency which in turn leads to better communication and understanding among all team members .    If you have an opinion on this topic – jump into the conversation.

Everybody Loves Agile

In a blog post on the SDTImes website (“Agile Making ALM Teams Work Faster, More Open”), Jeff Feinman takes a moment to share one aspect of a larger article he’s working on about agile life-cycle management (ALM), but that one aspect is a big one. According to Feinman, as he’s surveyed dozens of ALM companies about how they deliver their processes, ALL of the companies he’s talked to report that “100% of their customers are at the very least thinking about adopting agile processes.”

Though agile has soared in popularity over the past year or two, this is still a staggering update, illustrating just how widely agile adoption truly is. Still, one enduring impediment to adoption is the desire for organizations to implement a tool, rather than a process. Anders Wallgren, CTO of Electric Cloud, explains: “Part of what takes a thing like agile some time to get adopted is, I think, naturally, we want to buy a tool, not a process. So if I hear about this thing called agile, I’ll say well, ‘Where do I buy the agile software package?’ It’s a little difficult to get people to change their processes.”

Of course, some tools are designed specifically to reinforce that process. As I’ve mentioned here before, my team manages its projects using Scrum. Because Danube’s tool ScrumWorks Pro was created with the framework in mind, it complements my team’s activities perfectly, while giving new team members a guide rail to help them follow Scrum’s processes.

The First Tool for the Enterprise

Finally, it seems agile tools are catching up to the real world demands placed on organizations managing large, complex projects with agile methods—especially those companies who are developing products with shared components. While agile tools have done a great job of connecting teams to help keep even un-collocated team members frequently communicating, the biggest drawback of agile tooling options has been their capacity to translate in complex development environments. For example, it’s extremely common for large organizations to develop applications which are then utilized in multiple products. However, no tool has satisfactorily addressed that issue, making it near-impossible for such organizations to gauge the overall progress of a project, since it includes multiple backlogs.

But ScrumWorks Pro 4, which has just been released by Danube Technologies, has taken some big steps toward giving enterprises the ability to accurately track progress in situations like these. In the latest release of ScrumWorks, its two-paned interface highlighting the sprint and product backlog has been expanded to include a third view: the release planner. The release planner will allow users to define product features at a high level and assign themes (i.e. searchable/sortable tags) to the various products that will utilize this feature. Because programs (or “epics”) are created using themes, ScrumWorks 4 offers highly flexible program management capabilities and, importantly, allows users to configure the tool to reflect their own development activity, rather than work around the limitations of a tool.

If you’d like to learn more about ScrumWorks 4 and its features, head here.