I am currently studying with a view to attempting my PSM-III, if I stand any chance of passing I need to go back to basics to make sure I have a rock solid understanding of the fundamentals. With that in mind for the next few weeks I’m going to go back to core scrum and share my views on some of the fundamentals.
You can’t get a lot more fundamental than the sprint. The scrum guide defines a sprint as
In scrum we plan work in timeboxes, usually 2-4 weeks. By working to a much shorter planning horizon we can gain a lot of confidence as we go by reviewing progress frequently and adapt as required as the project goes along.
It is not a release schedule!
Many teams I have worked with attempt to set their deployment schedule with their end of sprint. These should be entirely coupled, DevOps has lots of good ideas about how and when to deploy. Deployments should be done as required throughout the sprint.
The sprint is about setting a goal and a timebox to achieve it. By having a consistent length of sprint we can gain confidence in the amount of work which can be delivered by looking at how much has been achieved in previous sprints. This is the purpose of velocity and estimation (a useful tool, if not a scrum process).
During the sprint:
In other words the team should focus on the objective of the sprint (the sprint goal) and not get distracted and put it in jeopardy in favour of other work.
Quality should be at least as high at the end of the sprint as it is at the beginning, one or more increments of work should be completed should be produced and all should meet the Definition of Done. If it isn’t “Done” then it shouldn’t be included and may be picked up in the next sprint. Testing phases and hardening sprints are categorically not scrum. Each price of work should be a high quality, done, potentially shippable increment.
Refinement of upcoming work and investigation of planned work continued as time goes on. Remember a sprint goal can be achieved even if the method and approach is refined as the sprint goes on.
So how long should a sprint be? This comes down to the development team in question. Generally a more work can be done in a longer sprint, however there’s more risk that something will arise which would invalidate the sprint goal. For this reason sprints should not be longer than one month.
Finally, if at any point the sprint goal becomes invalid the Product Owner may cancel the sprint. This could be for a number of reasons. The priority of work may have changed dramatically due to customer needs or the discovery of a bug (shorter sprints help prevent the waste of cancellation here). Or, the team may discover as they progress that the goal is impossible or not as valuable as originally believed. We’re in the business of doing effective work. If we discover that work isn’t going to be valuable our job is to avoid waste and move onto something which would be.
There’s probably a lot more I could add but hopefully it’s a good introduction. Do follow along for the rest of the series, next week will be Sprint Planning!
This week I want to talk about the two most important rules you can follow if you want to deliver great work and hit goals. Regardless of whether they’re software projects, books you want to write, or exams you want to pass. They are utterly underwhelming…
There you go, I told you they were underwhelming!
However, I want to go a little deeper (otherwise this would be a very short post).
Failure to start is one of the biggest reasons people don’t do things. How many times have you planned to do something one evening only to get home and fail to do it? The reason (according to James Clear in his book Atomic Habits) is because it takes energy and effort to start doing things. Far too often our brains follow a pre-programmed pattern to avoid decision fatigue. Do you want to go running tonight or watch television? What do you need to do to start running? You’ll need to get changed, then you’ll need to find your trainers, then you’ll need to actually do the running… oh, and then there’s the shower. But the TV remote is just there.
In his book James describes ways to reduce the friction required to take on these individual habits and actions and make them easier to do day to day. I do this myself. I want to listen to audiobooks each day, so I leave my headphones by the side of my bed so they’re the first thing I pick up each morning. If you want to go for a run after work then put your kit on your bed before you leave in the morning – or even better put it on before you leave the office so it’ll actually be more effort not to go for a run than it will be to just get out the door!
Once you’ve got started that’s a huge step forward. But a single run doesn’t make you fit. A thousand words doesn’t make a book. So how do you keep that momentum going day after day to make progress until the work is done?
The first step is to understand what “Done” is. Is there a done? If it’s about fitness then you may be looking for a particular weight or time, but you may also be looking to maintain. If you’re building a product you may be looking for a number of active users. Just like in product management and software development we should always be clear about what we want to accomplish before we set off. We can evolve that view, but it helps to act as a beacon.
This leads directly into the motivation question. If we understand our objective we can track our progress towards it. Visibly seeing our progress towards a concrete goal is a very powerful motivational tool (as well as the other benefits of transparency and adaptibility). Burn up charts for your personal goals may seem like overkill, but they’re really not.
Here’s my burn up chart for my reading goal (you can see I actually made the goal far more ambitious because I was doing so well).
You can see I’m doing something similar with my cloud computing exams. This one isn’t going so well, and what am I going to do about it? Revalidate the goal, recalculate the effort and expectations, and then really myself. As with all things agile create transparency, inspect, and adapt.
I know this post started a little tongue in cheek but hopefully it helps and has provided some valuable tools to meet your own goals. Don’t forget, start… and then continue until you are done!
Last year I finished wirint Code Black and published it on LeanPub. It wasn’t an easy challenge, although I enjoy wiriting I’ve never written a technical book before and had never really self published anything.
This week I wanted to share some of the lessons learned since writing the book which I took into my current project Donuts and Dragons.
Lesson 1 – You’re going to sell a lot fewer copies than you think you are! I had plans of the book becoming a runaway best seller, and to be honest I’ve genuinely been overwhelmed by the positive feedback I’ve recieved (even some suggestions I should enter it into competitions). However, I’m still working as a Dev Manager and have no plans of retiring and living off the royalties just yet.
Lesson 2 – Scheduling a “writing day” doesn’t work. Firstly, it’s too much to expect yourself to write for 8 hours straight. Second, if something cancels that day then you’ve lost a lot of potential words. The best way to write is to a schedule. When writing D&D I set myself a goal of about 500 words every week day. The book doesn’t appear overnight, it appears incrementally and inevitably.
Lesson 3 – Plan what you’re going to write. Maybe this comes down to personal style? Or maybe it’s because both of my books are trying to teach rather than just entertain but I would have got completely lost if I hadn’t had my trusty outline. Procrastination occurs most often when you don’t know what you’re going to write, having a plan – even a high level one makes it easier to hit that word goal.
Lesson 4 – Be proud of what you’ve done. When I first released Code Black I found myself belittling it. When someone said “Adam’s written a book” I’d say something like “Yeah, but it’s only a self publish.” or “Yeah, but it’s not sold many copies.” Don’t put yourself down, you wrote a book. That’s amazing, it’s something millions of people want to do but few ever actually succeed. Don’t you dare undermine what you’ve done.
Lesson 5 – You’ll want to write another one. Writing a book is a lot like doing a marathon. At the time you’ll swear blind that you never want to do it again. Then your mind starts ticking and you starting having those ideas and before you know it you’ll be developing characters and outlines again. Why not!? You’re an author now!
Oh, and something a lot of people ask me what has been my proudest moment since publishing it? That one easy – when Gene Kim bought a copy!
There’s a certain irony that the characters in my book read The Phoenix Project, I do hope he smiled at that.
Have you written a book? Tech or otherwise – please share it with me, I love to read what other people have done!
I was expecting lots of information about giving feedback but I was pleasantly surprised that there was a lot more in there than that.
Scott discusses that to be great leaders and team members we must both care personally and challenge directly. Without these two qualities we fall into one of three other quadrants.
People who care but don’t challenge fall into Ruinous Empathy. These are the people who won’t tell a friend that they’re unzipped because they’re afraid of the conversation. They’d rather let their friend continue to embaress themselves rather than push themselves out of their comfort zone.
People who don’t care personally are split into one of two categories. If they do challenge but don’t do it with someone elses best interests at heart then they display obnoxious agression. Or, simply put are just jerks. If they don’t challenge then they see what they could do to improve and don’t do anything to help them. This is manimulative insincerity.
Scott teaches us that we must always strive to give direct feedback to people we work with because we care about their success and their feelings. She also discusses lots of ways to do that.
I’d been expecting much of this content before I started the book but what delighted me was the actionable advice on how to go about this. I want you to read (or listen) to the book so I won’t give it all away here (plus, you know, plagurism). Suffice it to say that if you do now feel you should give feedback there are lots of tips in there to help.
But this is just for managers right?
Kim discusses that everyone should feel they can give feedback. Peer feedback is one of the most valuable thing we can give, it shows we care about our colleagues.
So, would I recommend it. Absolutely – go and have a read. Stop being ruinously empathetic today and start supporting your friends and colleagues directly!
I recently read Waltzing With Bears by Tom DeMarco and Timothy Lister, these are the same guys who wrote Peopleware so I was curious to give it a read as I found Peopleware useful, if a little dry.
Waltzing with Bears is all about managing software risk. Specifically the risk that something will not be delivered on time. The example the pair give early in the book is an airport which couldn’t open because the software to operate the baggage carousel wasn’t working. A late software delivery had huge financial impact.
In the book the authors talk about different ways to identify, represent, and manage risk. Like their other book Peopleware Waltzing with Bears is very comprehensive walk through of software risk covering a lot of the basics as well as some really interesting topics such as how to show delivery dates in a graph format to show the earliest possible, most likely, and worst case delivery dates. Thereby giving far more context than a best guess (which as we all know has a bad habit of being communicated to clients and becoming a deadline).
The authors made a very nice point about the bold being the ones who start projects early, not the ones who set ambitious deadlines and expect people to hit them.
However, I couldn’t help feeling like the authors were missing a big piece. The entire book (which I admit isn’t a long one) is based around delivery date risk. There’s no mention of many of the other risks which software teams face including usability, tech debt, and the ever present security risks. I would have liked to have seen more (well, any) pages dedicated to risks which aren’t about the due date. I felt like we were given a comprehensive introduction, but at the expnense of a breadth of knowledge of how to manage other risks.
Overall a good book which is well worth a read to anyone getting started in project planning and wants to understand how to manage the risk deliveries will run late. However, only a 4* read for me.
What do you think? Have you read Waltzing with Bears? Post your comments below!
Over the last year I’ve invested time in trialing and adopting apps which help my productivity. In this post I’m going to share them and explain why I believe they’re invaluable.
Todoist is an easy to use and intuitive TODO list application which supports projects, due dates, reminders, tags, and filters. It’s easy to use and syncs effortlessly across devices. I use it for everything from management work projects to keeping track of shopping lists and birthday presents.
The premium version unlocks additional features and it is well worth the money.
However, be aware downloading Todoist is enough to organise yourself. No tool can do that if you don’t have a system in place. I strongly recommend having a look at
Forest is an app which encourages you to put down your phone. I’ve written about it before and continue to use it. You can set how much time you’d like to “lock” your phone for and if you pick up before then your tree will die. Planning trees leads to gold which you can use to purchase more tree designs in the store or even plant trees in real life!
I started using this app this week and I’m really impressed. The premise is incredibly simple, the app records a quick message and then emails the text to the email address of your choice. Install on your watch and configure to the email of your Todoist inbox for a really effective way to record notes wherever you are and drop them right into your digital in tray!
Again, Audible shouldn’t be a surpise to anyone who’s read some of my recent blog posts. Listen to audiobooks while you’re driving or doing housework for a really effective way to consume books you wouldn’t ordinary have time to read. Especially if you practice building up your speed until you can listen in hamster mode!
And A Setting for Luck
Chances are your phone has a time limiter built in already, configure this to limit access to those time sync apps to 30 minutes each day. Being asked if you really want to spend your fourth hour on Facebook (or social network of choice) really is a great way to get you off your phone!
What are your favourite productivity apps? Do you use any which aren’t on my list?
This is a question I hear a lot, people have heard of (or may follow) Scrum and often have read about DevOps. They want to know whether DevOps is a replacement for Scrum or if it’s something they should be doing as well. Others believe that Scrum and DevOps are incompatible, in this post I want to talk about what both of these are how (because spoilers – they can) they should be used together.
What Is Scrum?
Lets start with the obvious question, if we’re going to discuss how DevOps and Scrum interact we need to define what exactly what we mean.
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
The Scrum Guide
The Scrum Guide is an extremely concise and valuable guide to Scrum. If you haven’t read it I strongly recommend you do. However, for the purpose of this post I’m going to to highlight a few points.
Scrum employs an iterative, incremental approach to optimize predictability and to control risk.
An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
Various Sections of The Scrum Guide 2020
When many people think of Scrum they discuss the Scrum Events, these include Sprints, Retros, Planning Sessions, and Sprint Reviews. However, equal importance should be given to the underlying theory of empiricism and incremental nature.
Each Scrum Team should deliver at least one increment of work each Sprint, this increment should be potentially releasable, and meet the Definition of Done. They will then meet in a Sprint Review meeting and discuss what they should do next to deliver maximum value.
What Is DevOps?
DevOps is, at it’s core an effort to reduce the divide between development and operational teams. Literally, Dev-Ops there are many practices and ways of doing this from the cultural to the technological however what has most likely led you to this post are the ideas of Continuous Integration, Continuous Delivery, and Continuous Deployment. Again, DevOps has many valuable lessons, I’m focusing on these three not to devalue the other concepts, but simply because they are some of the key concepts we need to understand for this article.
Continuous Integration requires that each developer merges their code into the master branch every day and if the master build breaks it is resolved or rolled back within ten minutes.
Continuous Delivery is a promise that any code which is the master branch is always in a potentially deployable state. Untested and unverified code is never merged in.
Continuous Deployment is an automation mechanism which pushes whatever is in the master branch into environments (often production) without any manual steps.
As you can see these are cumulative, so teams may practice Continuous Integration but may not practice Continuous Delivery or Continuous Deployment. It is also nearly impossible to practice Continuous Deployment unless you also follow Continuous Delivery and Continuous Integration.
It’s also worth mentioning the “3 Ways of DevOps” these were popularised by the highly successful book The Phoenix Project. The 3 Ways are:
Amplify Feedback Loops
Culture of Continual Experimentation and Learning
Using Scrum and DevOps Together
Now that we’ve talked about what Scrum and DevOps are (or at least highlighted some of the relevant and key parts of each) I want to discuss whether these concepts can work in harmony together.
The first aspect to address is the Scrum concept of an increment. The Scrum Guide says that each team should produce at least one increment of “Done” software which is potentially releasable to production each sprint. I believe that the three concepts of Continuous Integration, Continuous Delivery, and Continuous Deployment are not only compatible, they are the natural evolution of this requirement.
If an engineering team is following CI, CD, and the other CD then each day (or less) a piece of work should be added to master. This means that a typical team of 7 engineers working a standard two week sprint could easily produce seventy or more increments in a single sprint. They key here is that by breaking down the Scrum Product Backlog Items down into single pieces of work which can be individually developed with a single day and then tested in isolation. This is not easy, however with practice and strong story splitting skills it can be done.
It’s also worth mentioning the Definition of Done. The Scrum Guide states that each increment must meet the Defintion of Done. Continuous Delivery states that the master branch should be always be in a deployable state. What a high performing Scrum/DevOps team should do is write automated tests which execute against incoming pull requests into their master branch to confirm that it always meets the agreed Definition of Done. This not only reduces the amount of repetitive testing work expected of the team but it highlights immediately when a proposed increment does not meet the team’s Definition of Done. If it doesn’t, it’s not merged in.
Before wrapping up I also want to consider the 3 Ways of DevOps I discussed above.
By building the Definition of Done into the Deployment Pipeline of the product we support the 1st Way by ensuring that the requirements of the team are baked into the pipeline.
The 2nd Way is to shorten feedback loops. Scrum emphasises the value of engaging with stakeholders frequently to ensure that they are involved and know the current state of the product. Scrum is also based on empirism, the belief that only we can only make estimates by looking at real data, by valuing the 2nd Way and shortening those feedback loops wherever possible this gives us a more accurate picture of what impact our changes have had. Simply put, this more accurate view provides the transparency we need to inspect and adapt. These are the three pillars of empirism.
Scrum also defines an event, the Retrospective where team members should meet to discuss ways to improve the quality and effectiveness of the team. This fosters the experimentation and innovation expected of the 3rd Way. These ideas aren’t working against each other. Scrum is providing events to ensure that the DevOps approaches are being honoured.
DevOps is often seen as a Scrum upgrade or perhaps a replacement to the agile framework. However it shouldn’t be. I believe that many of the automation and development strategies of DevOps are the natural evolution of Scrum principles and fit very neatly into any team already using the process.
With automated tests continuously testing each increment to guarantee that it meets the team’s Definition of Done increments can become smaller and a continuous flow of high value work can be delivered with shorter lead times and higher quality.
This is a question I get a lot, what are Scrum Alliance and Scrum.org and which is “best”? The truth is there is no best, both have different certifications and a different business model. In this post I want to explain the differences between the two and help you decide which to choose.
Let’s start with what they do. Both Scrum.org and Scrum Alliance offer training courses and certifications for Scrum Masters and Agile Professionals. Both offer a variety of courses for Product Owners, Engineers, and other professions but in this post I’ll focus purely on the scrum masters.
You can think of these organisations like Exam Boards, if you pass their exam you get a certificate which you can present to any employer and it will prove that you have a certain level of scrum knowledge. You can also show the badges off to your friends and family but personally I’d recommend against that. I spent half an hour explaining to my mum that a Scrum Master had nothing to do with Dungeons and Dragons…
Both organisations offer three levels of Scrum Master certification. For Scrum Alliance these are the Certified Scrum Master (CSM), the Advanced Certified Scrum Master (A-CSM), and Certified Scrum Professional Scrum Master (or CSP-SM). Scrum.org offers the Professional Scrum Master levels 1, 2, and 3 (more commonly known as PSM-I, PSM-II, and PSM-III).
Personally I hold the CSM from Scrum Alliance as well as the PSM-I and PSM-II from Scrum.org.
Where these organisations differ is in how they go about granting the certificates. Scrum Alliance require you to attend a training course organised by a certified trainer. The prices of these vary depending on whether they are being held remotely or in person, which country they are being held in, and the level of the course. Typically in the UK you will pay around £700 for a remote course and £2000 for an in person one. Obviously the trainer then pays a fee onto Scrum Alliance. Once you have completed the course you will be sent a link to take the exam on Scrum Alliance’s website. If you pass (the pass mark is 37/50 questions) you’ll be awarded your certificate.
Scrum.org also offer training courses. However, their courses are not a prerequisite to taking the exam. Personally I have never done a Scrum.org course, I simply logged onto the website and purchased the exam token. These vary slightly depending on level but the PSM-I exam is $150 dollars.
It is also worth noting that Scrum Alliance certificates expire and you will either need to attend another course or pay (about £30 I believe) to renew it every couple of years. Scrum.org certificates do not expire.
The next most obvious question is which is easier!? There is a general feeling that the Scrum.org exams are a little more challenging, however I’ve never seen any data to back this up. Personally I scored a couple of percent higher on the Scrum.org exam than the Scrum Alliance one however not enough to state clearly. If you’re looking for a simple answer on which one would be easier to achieve or which holds more market value then I can’t give that. I would say however that the PSM-II (and I assume the A-CSM) covers significantly more ground than the PSM-I and asks questions based drawn from personal knowledge rather than simply knowing the subject matter. There is a distinct step up in difficulty and, although I’ve never taken it I wouldn’t be surprised if the PSM-III was far more challenging again.
So there you have it, all the differences that I’m aware of between the two organisations. If you’re looking for a taught course with a certificate at the end then Scrum Alliance may be for you. If you’re interested in self study and funding then Scrum.org may be the better alternative however I’ve found that both are extremely high quality certificates.
I’ve had this book for a while and it finally reached the top of my Audible list. Measure What Matters has intrigued me for a while, especially as I am focusing on setting and meeting goals at the moment.
I have to confess to being a little disappointed. At it’s core the book discusses OKRs, a kind of public goal which does a very nice job of splitting out the goal and the actionable tasks required to complete it. Visibility creates transparency to make sure no teams are duplicating effort or conflicting priorities, they also allow people to assist each other in meeting their goals.
So far so good, I didn’t have a problem with any of that.
However, the majority of the book was a list of testamonials from the author’s long list of supporters. It was genuinely interesting to see how the technique has been applied to everything from IBM to U2. But I’m really not sure wheeling out the famous and successful was really needed (in the audiobook many of them actually contributed their parts). It felt more like a sales pitch of OKRs rather than a practical guide of implementing them.
I kept finding myself expecting the next chapter to be a “How to get started with OKRs in your business.” but alas, it never came.
Enlightening by adding a new way to think about goals, however disappointing because although I’m intrigued I feel far from equipped to take advantage of the concept.
Do you agree? Have you read Measure What Matters? What did you think?