Scrum and Agile for devops

Posted on 16. Jul, 2013 by ger in Agile, Guides, Scrum

agile-scrum-resources-devops-training-dublin

Devops engineers were part of two recent Agile and Scrum training workshops I ran in Dublin. Here’s some resources that you might find useful if you’re coming to agile from a devops perspective.

Blogs and blog posts

Two of the best blogs I found are the Agile admin and Agile Web Operations. The Agile admin has a good post describing Scrum from an ops perspective. Some devops teams combine Scrum for longer term projects and Kanban for shorter term work. This blog post I wrote recently summarizes a great article by Jim Coplien about the linkages between Kanban and Scrum.

Books

These books include sections on agile devops

  • Scott W. Ambler; Mark Lines, Disciplined Agile Delivery.
  • Paul Swartout, Continuous Delivery and DevOps
  • Michael Hüttermann, DevOps for Developers
  • Jez Humble; David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

Learn more

Try Goshido, our collaboration & project management platform. Goshido is so flexible it can be used for Scrum, Lean and projects with traditional work-breakdown plans. It’s great for both long and short term devops projects.

Photo Credit

Internet Splat Map by Steve Jurvetson

User Stories for Agile Requirements Management

Posted on 26. Mar, 2013 by ger in Agile, Guides, Scrum

We use “user stories” to document and manage requirements. Recently I provided training for one of our customers. Here’s some interesting resources we recommend.

What are user stories?

User stories are a short placeholder for a detailed conversation about requirements – deferring detail until needed. Stories represent customer value and are written in the customers’ terminology.

The general formula for a user story is: As a <type of user>, I want <some activity> so that <some reason>.

For example: “as a registered user, I want the system to warn if my password is easy to guess, so my account is harder to hack.”

Why use them?

I’ve seen studies which state incorrect requirements are the cause of 80% of software project failures. User stories are a simple, low-overhead way of documenting and managing requirements.

Resources

One of the trickiest parts of using user stories is breaking them down to the right size. Richard Lawrence has written an excellent pattern language to help you in this process.

There’s been an interesting debate on the value of acceptance testing.

We recommend the following books:

  • User Stories Applied: Mike Cohn
  • Agile Software Requirements: Dean Leffingwell
  • Specification by Example: Gojko Adzic
  • The Art of Agile Development: James Shore

Learn more

Try Goshido, our collaboration & project management platform. Goshido is so flexible it can be used for Scrum, Lean and projects with traditional work-breakdown plans. It’s great for managing product roadmaps and requirements documented as user-stories.

Project Collaboration Overview & 7 Great Books : Siemens Talk

Posted on 12. Mar, 2013 by ger in Agile, Events, Guides, Leadership, New Ways to Work, blog

Last night in Dublin I spoke to a group leaders from Siemens at an event coordinated by WDHB.

The key points of my talk were:

  • Existing tools still don’t solve the problems of communication within large organizations
  • Businesses need a flexible system that can scale from gigantic to many small-informal projects
  • Culture is even more important than tools. Agile ways of working & leading with short iterations and empowered teams are crucial.

I recommended a number of books that explore the last point:

  • Radical Management: Stephen Denning
  • Succeeding with Agile: Mike Cohn
  • The Future of Management: Gary Hamel
  • Management 3.0: Jurgen Appelo
  • Getting Things Done: David Allen
  • The Way We’re Working isn’t Working: Tony Schwartz
  • What Were They Thinking?: Jeffrey Pfeffer

Other speakers at the event were Marie Wallace of IBM and Polly Sumner of Salesforce. Polly recommended a really interesting followup action at end of her talk. She suggested everyone in the room try to buy or get customer support for their own product.

By coincidence I read the following quote in the Siemens “Pictures of the Future” magazine this morning.

    “Modern information and communication media promote a short attention span and a superficial understanding of the world.” — David Gelernter.

By another coincidence I read this in the Chess Media newsletter this morning.

    “Communication barriers cost large companies an average of $26,000 per employee per year due to productivity losses.” — Jacob Morgan

Learn more

Try Goshido, our collaboration & project management platform. Goshido is so flexible it can be used for project collaboration in any kind of business: product development, energy, healthcare & consulting.

You can download my slides.

Project Collaboration Roundup: structured fighting, project timebombs, productivity guidelines & Enterprise 2.0

Posted on 23. Sep, 2011 by tom in Guides, New Ways to Work, Roundup, blog

We know that it’s hard to stay on top of all of your activities. That said, it’s rare that we think of our projects as ticking time bombs. This week we have some useful rules and advice about productivity, and lots of good thinking on collaboration and new ways of working socially.

project collaboration productive fight

John Morehouse by KrissZPhotography

Clay Shirky on collaboration: structured fighting

In a story by Joe Brockmeier posted on ReadWriteWeb, a talk by the always thought-provoking Clay Shirky hits on some important points, and an interesting metaphor. As we like to preach here at Goshido, large projects are really made up of lots of small projects, and lots of actions.

Are your projects out of control?

First, the bad news. According to a study conducted by Professor Bent Flyvbjerg, BT Professor and Founding Chair of Major Programme Management at the University of Oxford one in six projects are “out of control.” Late, over budget, and out of control is no way to go through life. When I saw the phrase “ticking time bomb,” I certainly took notice.

Perhaps some rules for productivity would help?

A presentation from Dan at Lostgarden covers eight common workplace topics and how you should approach them. It’s important to remember that productivity is more than just more units produced per unit worked, and the pdf or powerpoint (take your pick) provides some strong guidance.

The Big Failure of Enterprise 2.0 Social Business – by Laurie Buczek

And ideas about how to fix it from the trenches. Three key takeaways:

  • Focus on creating a natural collaborative experience
  • Focus on providing an easy & intuitive user experience
  • Focus on dissolving collaborative islands- don’t create more with social tools

Thank you for reading

We hope you found something useful. Please try Goshido, our collaboration & project management platform. Goshido can help you and your teams to take action in the absence of orders and communicate with clarity.

Photo by KrissZPhotography, available under a Creative Commons attribution license

Cloud Computing Demystified

Posted on 15. Sep, 2011 by ger in Guides, New Ways to Work

Cloud computing can have huge benefits for a business of any size. If you’re running a small business you can share information and use world class software without up front costs. If you’re a large business you can consolidate complex applications onto less hardware, run them on someone else’s computers and access them over the internet.

collaboration-project-cloud-1

I am one of the panelists at the Irish Executives conference in Galway Ireland on 15-Sep-2011. Here are some resources (articles, videos and books) that might help you learn more about the cloud software and how it can benefit your business.

Thank you for reading

We hope you found something useful. Please try Goshido, our collaboration & project management platform. Everyone is a project manager these days. Goshido helps teams of all shapes and sizes to get things done.

If you trial Goshido using the link above, you’ll get a 40% discount for you and your team if you decide to purchase.

Photo by barto, available under a Creative Commons attribution license

Agile for any organization – a guide

Posted on 16. Jun, 2011 by ger in Guides, New Ways to Work

Agile management techniques have been used successfully in software and development in recent years, but can they be used to run other kinds of business? I believe they can. If you want to transform your business into an empowered, self-organizing machine that performs better, read on.

In this guide to agile I will, tell you three stories which will hopefully:
- Outline the benefits Agile
- Point out some tips and pitfalls
- Suggest some further reading

It’s about 13 years since I first encountered agile management. At the time I realized we were already naturally using some agile ideas, we just didn’t know they had a label. As you read this guide you might say “We already do that.” If you do, congratulations, you’re some way down the agile road already. Learning a little more will help you see the bigger picture and get even more out of agile.

Agile before we’d heard of Agile

Around 20 years ago (I’m really dating myself now) I worked for a US multinational building software for managing networks of telecom equipment (for a new standard called GSM). The project had run for a number of years with a large team and we had little working code to show but lots of specifications and elaborate plans.

A number of us felt a growing sense of unease so we put together a small team of five engineers and decided to rapidly build a simplified version of the overall system. Our small project was going to be a backup plan for the main team – risk mitigation. The other seventy engineers kept working on the existing plan. Can you guess what happened?

Our small team didn’t put any big plan in place. We commandeered a small meeting room and drew a list on a big whiteboard of the phases of the project. Each engineer owned a specific area of the product. We didn’t work in our regular cubes, we worked together in the meeting room. We lived and breathed that project. In effect the product was built during an extended ten-month meeting.

When the big team tried to put all their pieces of software together, they wouldn’t fit. Then we demoed our simplified product. It was fast, elegant but most importantly – it worked. The simplified product, built by five engineers in a small meeting room, became the basis of future products by that company for many years.

How did we do it? We had a simple goal, a simple plan, a deadline not too far away & we continuously reviewed progress and made many small adjustments. Management didn’t interfere but more crucially provided air cover for our small team. We were agile but didn’t know it.

First successes with Scrum

A number of years later I was working on another project that hit a problem. We realized a crucial software subsystem was more complex than we had estimated, the subsystem was underresourced. Our reputation was on the line. We had five months to turn it around. In a previous company I had been experimenting with two new management techniques, one called Episodes and one called Scrum. To my eye they looked very similar. Episodes went on to become Extreme Planning and Scrum went on to become er Scrum.

Again we put a small team together, this time four engineers. We split the overall project into a series of five month-long sprints. We then focussed only on the current sprint. We held daily meetings and everyone planned their own tasks each day. For each task we put post-it notes on a big A2 sheet of paper on a table in the middle of our work area.

We built the crucial subsystem in five months and three days, which for a software project is remarkably close to the deadline.

Our next project, spanning 15 months with 30 engineers (6 teams of 5) mostly used Scrum. This project we completed one week early (which is very rare in software projects). Other teams in the organization started using A2 sheets and daily meetings. The company’s post-it note bill skyrocketed. Projects hit their deadlines.

I think there were a number of key factors in these successes:

  • Everyone on each team had a sense of ownership both of the project and their own destiny.
  • We didn’t spend time building intricate and brittle long-term plans.
  • Everyone was focussed on a tangible milestone, at most a month away. We didn’t have time to delude ourselves into a false sense of being-on-track. We didn’t change plans during each sprint.
  • We met almost daily and made many small adjustments.
  • We created a simple visualization of the project and progress.
  • Everyone, even the graduate engineers, became a project manager of their part of the project.
  • We held retrospectives at the end of each sprint to decide what went well and what went badly. We saw genuine organizational learning.

Scrum to manage marketing campaigns

Recently Goshido began working with another multinational product company, but this time instead of building products this team was managing retail marketing projects in 13 countries. The team was running well and getting results, but each quarter-end they seemed to have an increasing backlog of open issues dragging into the next quarter.

They decided to look at their projects as sprints. Deciding what needed to be done in the first sprint (month) led to interesting and surprising debates about priorities. They quickly realised they were not all pulling in the same direction, they were being unrealistic and putting themselves under unconstructive pressure.

Today they’ve mapped out their projects at sprints. They’re not looking too far down the road. Instead of post-it notes, they’re using Goshido and their distributed team (some of whom are outside the company) have an always-up-to-date picture of what’s happening on the project. They spend less time in meetings, more time making progress.

We would wholeheartedly recommend the agile approach to running projects. The key challenges are not technological but sociological – resistance to change. Agile is a new way of thinking, but when your team starts thinking in that new way, they feel more empowered, more engaged and will improve your business performance.

Learn more

Kirsten Knipp’s blog post show’s you how to run a marketing team like an agile startup.

Read Mike Cohn’s blog post on how to decide if Scrum is right for your project.

The wikipedia article on Scrum will give you a good primer on the terminology.

Joe Little has written a short but great blog post about getting started with agile and Scrum.

Kelly Waters has written a series of blog posts outlining 10 easy steps to implement Scrum.

A recent HBR article by Eric T. Anderson and Duncan Simester suggests running a business as a series of experiments. Short test-learn cycles sound like the short iteration cycles of Agile.

Stephen Denning’s book The Leader’s Guide to Radical Management applies agile techniques to the organization as a whole, not just a single team or even a product development group.

Update 12-Jul-2011: Steve Denning has also published an excellent introduction to Scrum from a general management perspective.

Jurgen Appelo’s Management 3.0 is a tour-de-force showing how businesses are complex adaptive systems and how this theory can be applied to bring greater agility to any organization, team, or project.

Jurgen Appelo has put together a list of the top 100 agile books. Many of these books are specific to software engineering. I really liked Succeeding with Agile: Software Development Using Scrum by Mike Cohn.

Try Goshido, a new cloud-platform, which helps people: focus, communicate, and do their best work. Goshido applies new principles for how work can be organized; the perfect blend of Agile, Lean, Productivity and Attention Management.

Personal Productivity – a guide (FTF and GTD)

Posted on 04. Jun, 2011 by ger in Guides, New Ways to Work

If you’re feeling overwhelmed by all of the tasks and projects you have, then some personal productivity techniques might help. Maybe the five minutes you spend reading this post might save many hours of procrastination in the future.

I’ve experimented with a number of techniques in my time and two in particular made a big impact on me. In this post I’ll give you a quick guide to Stephen Covey’s First-Things-First (FTF) and David Allen’s Getting Things Done® (GTD®).

Getting Things Done (GTD)

Getting Things Done (GTD) helps you capture all of the tasks and projects bouncing around in your head into a system you can trust. It’s a bit different from other time management methods because it doesn’t focus on priorities. I’ve used GTD for a number of years and it is an excellent way to get and stay organized, calm and productive.

GTD – key concepts

Actions, are indivisible chunks of work. An action is something that needs to be done.

Contexts, are the situation in which an action can be completed. For example, an action that can only be completed in the office, would have a context of office.

Projects are activities that will take more than one action to complete. Each project has a desired outcome, a simple description of what success looks like. One of the key benefits of GTD is the idea that you should always identify the next action for a project. For example, if the project is renew insurance, the next action might be “get insurance company phone number”.

GTD has a simple workflow. You have a number of collections – notebooks, inboxes (electronic and real paper), voice recorders. You regularly process these collections and capture the actions. You can make a simple triage decision on each item in a collection:

  • Is it actionable?
  • If yes, and it will take less than two minutes, do it now.
  • If actionable, and it will take longer, defer it.
  • If not, bin it or store it for reference.

There’s a number of stages of the GTD “workflow”:

  • collect- gather possible actionable items
  • process – all the items and decide if they are actionable or not
  • organize & review – review your existing projects and actions, make sure every project has a next action
  • do – don’t forget to get things done

GTD Benefits

There’s more to GTD, but that’s the rudiments. When I’ve managed to apply myself for a consistent period of time I’ve found it excellent, felt calmer and more in control of my work. It does take some time though.

Getting the most out of GTD

The danger with GTD is you spend lots of time feeding the system, you could if you’re not careful, spend more time organizing than doing.

You really do need to do the weekly review every week – not every so often. The hard thing is stopping long enough to do the weekly review. I’ve let it lapse for a time and if you haven’t done a weekly review in more than a week you do start to feel harried and start to mistrust the system and feel like things are “getting a bit out of control” (instead of “getting done”).

The total number of projects starts to rise quickly. This is good and bad. It’s good because you become more conscious of the number of projects you’re involved in, they were all there in the back of your mind anyway. I found within a few weeks I was up to nearly 70 projects which is a lot to review weekly in just an hour. In the end I had to review only part of the project list. I used my “areas of responsibility” to prioritize my projects.

If you do read David Allen’s book and you’re not quite sure about GTD, try reading the book a second time at least a month later. I found the concepts made much more sense on the second read.

Tools for GTD

You don’t need any tools for GTD. You can do everything with a notebook and a simple physical filing system.

However, a number of excellent tools have emerged in recent years. On the Mac (and iPhone / iPad) you’ll find both Omnifocus and Things. Things is a very elegant and simple application. Omnifocus is more complex but more powerful. ThinkingRock is a java GTD application that runs on Windows (as well as Mac and Linux). All of these tools are for a single individual.

Our product Goshido is a platform for managing work. It runs on the cloud and any web browser. Goshido allows you to capture, organize and do: actions and projects. Goshido enables you to implement GTD either on your own or within a team.

GTD summary

One of the refreshingly different things about GTD is a lack of emphasis on priorities. The main idea is to select a next action based on context, on the day and in the moment.

If you’re finding you are harried in your day to day work and starting to feel out of control, give GTD a try, it could leave you feeling like you have a “mind like water”, a calm awareness.

Prioritizing work with FTF

A number of years ago I also tried using the productivity system outlined by Stephen Covey in his book, 7 habits of highly effective people. Habit #3 is “First Things First”. Covey recommends you decide the importance and urgency of each task.

This means each task can be categorized in one of four quadrants:

  1. Important & Urgent
  2. Important & Not Urgent
  3. Not Important & Urgent
  4. Not Important & Not Urgent

Many people spend too much time in quadrant 3 and not enough time in quadrant 2. Covey recommends intentionally tipping the balance toward quadrant 2, saying no or delaying tasks that arrive that are part of quadrant 3.

Years ago a US multinational I worked for sent us all on time management training. They recommended prioritizing tasks on a scale of 1-5. When I started using the Covey technique I found it much more effective.

As Dwight D. Eisenhower once said “Most things which are urgent are not important, and most things which are important are not urgent.”

Next Actions

Legalese

Goshido is not licensed, certified, approved, or endorsed by or otherwise affiliated with David Allen or the David Allen Company which is the creator of the Getting Things Done® system for personal productivity. GTD® and Getting Things Done® are registered trademarks of the David Allen Company. For more information on the David Allen Company’s products, please visit their website: www.davidco.com.