DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Agile ITOps: Day 1

Agile ITOps: Day 1

James Betteley user avatar by
James Betteley
·
Dec. 01, 12 · Interview
Like (0)
Save
Tweet
Share
4.36K Views

Join the DZone community and get the full member experience.

Join For Free

today we started day 1 of our first ever itops sprint. this all came about because we needed a way of working out our productivity on “project tasks”, as well as learning how to triage our interruptions a bit better. none of the it ops team had tried any form of agile before, so there’s a mix of excitement and apprehension at the moment! i’ve opted for the old skool cards and sprint board (we’re using scrum by the way – more on this in a bit) rather than using an it based system like jira. this is mainly because everyone’s co-located, but also because i think it’s a good way to advertise what we’re doing within the office, and it’s an easy way to introduce a team to scrum.

the team already had a backlog of projects, so it was quite an easy job to break these down into cards. first of all we prioritised the projects and then sized up a bunch of tasks. we’re guessing, for this first sprint, that we’ll probably be around 40% to 50% productive on these project tasks, while the rest of our time will be taken up by interruptions (it requests, responding to inquiries, dealing with unexpected issues etc).

sprint 1 – planned, or “committed” tasks are on green cards, while interruptions go on those lovely pinky-reddish ones.

i’m using a points system which is roughly equivalent to 1 point = 1 hour’s effort. this is a bit more granular than you might expect in a dev sprint, but since we’re dealing with a very high number of smaller tasks, i’ve opted for this slightly more granular scale.

as well as project work, there was also an existing list of it requests which were in the queue waiting to be done. i wanted to “commit” to getting some of these done, so we planned them in to the sprint. i had originally thought of setting a goal of reducing the it request queue by 30 tickets, and having that as a card, but i decided against this because i don’t feel it really represents a single task in it’s own right. i might change my mind about this at a later date though! so instead of doing that, we just chose the highest priority it requests, and then arranged them by logical groupings (for instance, 3 it requests to rebuild laptops would be grouped together). at the end of our planning session we had committed to achieving approximately 40% productivity.

managing interruptions

we expect at least 50% of our time to be taken up by interruptions – this is based on a best-guess estimate, and will be refined from one sprint to the next as we progress on our agile journey. whenever we get an interruption, let’s say someone comes over and says his laptop is broken, or we get an email saying a printer has mysteriously stopped working, then we scribble down a very brief summary of this issue on a red/pink card and make a quick call on whether it’s a higher priority that our current “in progress” tasks. if it is, then it goes straight into “in progress”, and we might have to move something out of “in progress” if the interruption means we need to park it for a while. otherwise, the interruption will go in the backlog or in the “to do” list, depending on urgency.

at the end of the sprint we’re expecting to see a whole lot more red cards than green ones in the “done” column. indeed, we’re only a couple of hours into the first sprint an already the interruption cards contribute more than a 4:1 ratio in terms of hours actually worked today!

interruptions already outweigh “committed” tasks by 4:1 in terms of hours worked – looks like my 40% guess was a bit optimistic!

triage and priorities

one of the goals of this agile style of working is to get us to think a bit smarter when it comes to prioritising interruptions. it’s been felt in the past that interruptions always get given higher priority over our project work, when perhaps they shouldn’t have been. i suspect that in reality there’s a combination of reasons why the interruptions got done over project work: they’re usually smaller tasks, someone is usually telling you it’s urgent, it’s nice to help people out, and sometimes it’s not very easy to tell someone that you aren’t going to do their request because it’s not high enough priority. by writing the interruptions down on a card, and being able to look at the board and see a list of tasks we have committed to deliver, i’m hoping that we will be able to make better judgement calls on the priority, and also make it easier to show people that their requests are competing with a large number of other tasks which we’ve promised to get done.

why scrum?

i don’t actually see this as the perfect solution by any means, and as you might be able to tell already, there’s a slight leaning towards kanban. i eventually want to go full-kanban, so to speak, but i feel that our scrum based approach provides a much easier introduction to agile concepts. kanban seems to be much more geared towards an ops style environment, with it’s continuous additions of tasks to the backlog and its rolling process. i think the pull based system and the focus on “work in progress” will provide some good tools for the itops team to manage their work flow. for now though, they’re getting down with a bit of scrum to get used to the terms and the ideas, and to understand what the hell the devs are talking about!

retrospectives, burn-downs and continuous improvement

we’ll stick with scrum for a while and at the end of our sprint we’ll demo what project work we actually got through, as well as advertise the amount of it requests we did, and the number of “interruptions” we successfully handled (although i don’t think i’ll keep calling them “interruptions” :-) ). i’m also looking forward to our first retrospective, which we’ll be doing at the end of each sprint as a learning task – we want to see what we did well and what we did badly, as well as take a good look at our original estimations!

i’ll keep track of our burndown, and as the weeks go by i’ll try to give the team as much supporting metrics/information as i can, such as the number of hours since an interruption, the number of project tasks that are stuck in “in progress” etc. but most important of all, we’re looking at this as a learning experience, an opportunity for us to improve the way we manage projects and a chance for everyone to get better at prioritising and estimating.

i’ll keep the posts coming whenever i get the chance!

agile Sprint (software development) Task (computing) scrum IT Cards (iOS) Requests

Published at DZone with permission of James Betteley, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Fraud Detection With Apache Kafka, KSQL, and Apache Flink
  • How Observability Is Redefining Developer Roles
  • Upgrade Guide To Spring Data Elasticsearch 5.0
  • Mr. Over, the Engineer [Comic]

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: