Skip to main content

Beyond Scrum?

[Adapted from a post to our internal Slack team.]

My manager has been working to get an agile consultancy into our university's central IT department to help us progress in our journey toward being more agile. I hope that the training and coaching we receive will focus more on the root principles of value in agile processes rather than on a single process like Scrum.

Are there any root agile principles that you think we need to be better at embracing? Here are some that come to mind for me.
  • Develop functionality vertically instead of horizontally. You don't create the database layer all the way, and then the web services layer all the way, and finally--after 9 months--start to create the web user interface. Instead, you find a way to introduce a complete feature that touches all those technology layers so that you can get real feedback about the usage and value of the system or feature.
  • Be willing to throw things away. If we're going to experiment, we have to be okay building things "incorrectly" the first time. We won't realize it is incorrect or suboptimal, so we're not building it badly on purpose. But we don't want to be stuck in analysis mode too long. We want to get something to users that they can feel and give us feedback on. This is ultimately more reliable than our up-front analysis. (I'm not arguing for no analysis or design, just not to let it go on too long.)
  • Develop a culture of testing. This includes user testing, unit testing, A/B testing. Pre-release testing. Post-release testing.
  • Encourage teams to reflect on how their version of the project process is working. This is the concept behind a sprint retrospective. I've been really bad at encouraging this, but I should be better.
These thoughts were stimulated by receiving this article in my inbox this morning. "Life After Scrum: Development Methodologies for DevOps" https://www.gartner.com/document/3881076

Here are some interesting quotes from the article.
DevOps stalls unless organizations move past Scrum
Many people erroneously equate "doing Scrum" with "being agile"
Be aware that constraints to autonomy may be indirect. For example, teams cannot choose to employ an estimates-free way of working if they are subject to governance processes that demand estimates. Similarly, enterprise-mandated tools such as enterprise agile planning software may enforce processes.
This previous quote about tools guiding our process is one we definitely want to think about as we adopt NetSuite as our OIT ERP tool.
Accept that a short-term disruption is a part of growing into a high-performing team.

Comments

Post a Comment

Popular posts from this blog

Becoming a SharePoint Convert

SharePoint has always been in my peripheral vision, but never a tool that I actually used. We're in the middle of an investigation project to look at putting up an enterprise instance of it. I watched the Lynda.com intro training for SharePoint 2010 and I have to say that I'm quite impressed with how far SharePoint has come since my first introduction to it. It is sporting the ribbon interface from the Office applications that I've come to like very much. The ability to keep calendars, task lists, and even documents synchronized with Outlook is awesome. I wish it was a little more straightforward to save a document from Microsoft Word or Microsoft Excel in to your SharePoint work space for the first time. Right now, the interface feels a little broken to me. You click the button to browse for a SharePoint location to save, and word does absolutely nothing. You click the button again, and it still does nothing. It turns out that you have to click the SharePoint button, a...
Post a Comment
Read more

Hammers and Nails: Technology Push Design

"We need to refine our requirements first, before we look at tools." This is a common phrase that I hear. While I sympathize with the sentiment, I think it is frequently wasteful. I suspect that we'd get to the right requirements faster by looking at tools already available in a given problem space. Pushing the concept further, is it foolish to find a cool technology and then look for ways that that technology can apply to current problem spaces?  What if you don't even recognize you have a problem space? Without a constant search and openness, we'll miss many serendipitous opportunities. Here is BYU professor Larry Howell discussing this issue. I often enjoy doing something ... that is sometimes controversial. In this approach, rather than starting with a need, you start with a new technology and you search to identify a need that it can fulfill. This second more controversial approach is called "technology push design."   You can imagine t...
Post a Comment
Read more

Broader Process Sharing - Service Request Fulfillment

While at a BMC UserWorld conference a few years ago, I wrote the following. It still applies and I wanted to put it down in a permanent spot where I could find it later. ========== We're perfecting the Service Desk call center. What would it look like if we invited other campus support units to share our processes and tools, if not our Service Desk? My recent experience moving into a new building has sharpened my focus on this issue. I'd like to share a taste of my experience by way of introduction and illustration of my implementation recommendation. In my new office, I need to obtain keys, request door locks to be installed, deal with furniture alterations, move network and power outlets that were obstructed by furniture, request appropriate signage for our department, order new furniture, resolve electrical wiring problems involving and interface with the furniture, request building card swipe access, request thermostat adjustments, and request permanent placement of...
Post a Comment
Read more