Tag Archives: SCRUM

Nexus Overview

Episode 74

First guest author has arrived! Today’s episode is written by Kate Terlecka and will be an introduction to The Nexus Framework, a tool for Scrum scaling. Have fun!


What’s the most fashionable word in current agile world?


Yep. If you don’t scale you’re a lame 1999 oldtimer, not worthy of attention. Only Scrum? But you’re supposed to have BIG Scrum!

There is a reason why creators of two largest Scrum scaling frameworks refused to describe and name them for years. Only when SAFe started being marketed aggressively, they’ve had a change of heart. Bas Vodde and Craig Larman decided to name what they have been teaching for years LeSS (Large Scale Scrum) and Ken Schwaber decided to finally formalize and name Nexus. Read the rest of this entry »

1 Comment

Posted by on June 15, 2017 in Agile


Tags: , ,

Embrace the Change

Episode 33

Everything changes and nothing stands still.


          Software changes. Technologies change. Build systems change. Deployment environments change. Requirements change. Markets change. Clients change. Some people refuse to change though. How to deal with all that fuss without losing sanity?

Wind of Change

          This week’s episode of How To Train Your Java is hosted outside of the usual place, namely on my company’s tech blog, right here. Enjoy :)

Sweet Sixteen

          By the way, if you happen to be in Wrocław, Poland in four weeks from now and you are not afraid of Polish language, you are welcome to join my talk on principles in object oriented programming. I’ve titled it Sweet Sixteen (since there will be 16 principles). Its free, includes beer and pizza, you just need to sign up on the event page, right here.

          In the next episode I will do something I haven’t done for quite some time. I will show you some actual code. Stay tuned.

embrace the change


Posted by on September 1, 2016 in Agile, Sweet Sixteen, Technology


Tags: , , , ,

Glimpse into the past

Entry 13, Day 37

That was a long break, huh. But I’m back here and now. Let’s talk about the Sprint Retrospective. Time to stop running, look back and think about stuff we have just done.  As The Scrum Guide says: the Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. Inspect and adapt in a never-ending cycle of project lifetime.

Retrospective unleashes hidden demons so that they can be ceremonially butchered for the greater good of Scrum Team. And in turn – the Product.

 Dr Who

Retrospective is for the Scrum Team (Dev Team + Product Owner). PO should take part, but if the dev team feels that some issues should be discussed without PO, they can ask him/her nicely to leave for some part of the Retro. Scrum Master may also be asked to leave, but this is not recommended as the SM has  the power of insight “out of the box” not being the part of the dev team. Of course it might happen that the SM is the problem, that needs to be addressed, in which case, we have some kind of deep pathology anyway.

Any Scrum meeting is open by default for external observers unless the Scrum Team says otherwise, but in case of retrospective it’s often better not to let external spectators in, since it may cause team members to feel threatened and restrain from sincere feedback. This means, that if there is a manager who is not part of Scrum Team, he can be kicked out if the Scrum team says so. (I’m, not talking about who has authority over who as defined in the labour code, I’m talking about rules of Scrum here).

Who should lead the Retro? The common misconception is that it should be always the Scrum Master. Actually much better idea is if each time different person takes the lead. Everyone has a different style of mastering the ceremony, and variety is the key to unleashing creativity. Of course, if the team is new and unfamiliar with Scrum, the SM should take first few Retros to give them any clue how it can be done. And provide support later anyway.

Dr When

After each sprint. On occasion, you may perform Retros covering longer period, like half a year. Perhaps a specific period like first half year after product initial release or something like that. As any Scrum meeting it should be held at stable time – perhaps Friday afternoon, last day of the sprint is best. Don’t skip it till Monday since people will forget some stuff during weekend (and this is the purpose of a weekend)

Dr Why

Simply to improve. While learning any skill if you don’t stop and think what you blew up recently, your progress will be slower. Same is true for software development, and I don’t mean just coding or technical stuff. I mean the entire process from the bird’s-eye view, coding, testing, deployment, interactions inside and outside team, soft skills usage, corporate politics etc.

Dr Where

That’s actually an interesting question. You could do the meeting in the same place every time, but the point of Retrospective is to get the most creativity, memories and insight out of people. One trick to do that, is to perform it in some different environment, even unconventional. Think about going out, sit on a grass in nearby park, or in a pub, or even in a moving tram or boat. Seems silly, but…

Dr How

The biggest doctor. There is a myriad of possibilities when it gets to organizing the Retrospective. Sure, there are teams that for five consecutive years only do the red cards and green cards each time. Probably they should get a new Scum Master. If you stick with one routine way to do the meeting, people will be bored and you won’t get much out of them. Retrospective should be interesting and fun!  There are plenty tricks, exercises or games  to get people attention, some of them might be quite unorthodox.

Dr Five Stages

You can follow the Five Stages Model, as described in “Agile Retrospectives: Making Good Teams Great”, a must read by the way. So:

Set the stage – get people’s attention, spin cogwheels of their minds and set some theme for the meeting. And make them feel safe in order to get sincere output. Example: ask them to describe the sprint in one word (and hope it’s not “disaster”) or one emoticon. Throw stuffed toys at them, tell some fun story.

Gather data – get people to create a raw output. Classic way is to have green (good things) and red (bad things) sticky notes, give people 10-15 minutes to prepare a few and put them on a table. You can add third column like “ideas”. You can further divide the table into senses – related areas “I saw”, “I heard”, “I feel”. It will boost people memory. Moving motivators is nice idea and works well.

Generate insights – get people to crunch through what they gather, analyze, discuss, think, try to find the patterns. Talk about sticky note, elaborate, group them together. Encourage everyone to speak up.

Decide what to do – get people to figure out how to improve things. Generate some to-do list, decide what’s most annoying, what should be fixed first, what can be done inside the team and what requires external actions. You can maintain a so-called Impediment Backlog to help manage that kind of stuff.

Close the Retrospective – provide some kind of summary, make people feel good about what has been done during the meeting.

An interesting idea is Retr-o-Mat. It’s a simple page that lets you generate randomly the five stage scenario for retrospective from predefined activities. For now there is over million combinations, and that number is growing.

And what are your ideas for retrospective?


Leave a comment

Posted by on September 7, 2014 in Agile


Tags: , , , ,

The First Artifact

Entry 9, Day 16

     “The product backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.”

– Scrum Guide

Being recently in the tools department, let’s continue the topic and look for something to manage The Product Backlog.  But wait, what’s that?

As I’ve said, I’m not going to do full fledged Scrum here, because there is no point in that. However I will keep some of Scrum elements. For example, Scrum defines so called Artifacts. There is the Product Backlog, there is a Sprint Backlog and there is an Increment. I’ll keep the Product Backlog. I will probably not need Sprint Backlog. And we will see about Increments later.

So, the Product Backlog (or simply the Backlog from now henceforth) is where the idea of the product is kept. The idea might be more or less clearly and precisely defined, usually the higher the priority, the better the definition. The Backlog is composed of Items. Single Item might be a requirement, feature, enhancement, bugfix or anything that is going to change the product. Changes may be indirect and be without immediate value, say “Setup Tomcat” is actually an internal task, but it is required to proceed for me.

My needs are simple. I need a tool where I can add items in at least three categories – to do, ongoing and done. I need to be able to easily change priority (distance from top of the list), move between categories (say it’s ongoing / done) and edit Items. The tool should be cloud based (fancy term recently), free and publicly accessible.

In my work, we have mostly used Excel with quite advanced scripting (hi Kamil ;)) to help with moving, changing and calculating stuff. Sometimes we would just take a pin board and stick notes to it (It is common with Sprint Backlog, but not really with Product Backlog). Or simply there was no public Backlog whatsoever (well…).

But Excel has drawbacks. First, it is a desktop tool, and I want to share stuff in the blink of an eye. So, I could go for Google Spreadsheets, but still manipulating Items would require some effort. Let’s look for something more dedicated then. Quick research convinced me that there is an overwhelming number of tools to choose from. You can check out Wikipedia’s comparison of project management tools, You can then narrow the criteria to Agile tools. I’ve taken a look here and there. I’ve decided to give some of them a try.

So first, there is Jira. It was used by some teams around me. But apparently, it is not free, and is too big for my needs. We need simplicity. Out.

Someone mentioned when I was sniffing around. Unfortunately, while it’s simple, it’s also more of a calendar tool, not really good for me. Out.

Then, there are quite a few tools (I’ve checked iceScrum), that are open source, but there is no free hosting. Either you download and host by yourself or you pay. I want it quick, I want it now, I want it free. And I don’t have a hosting department operational yet. Out.

There are also promising tools closed source, but they are paid (e.g. Agilo for Scrum). Well, out.

There was one tool that was free and looked nice. The AgileFant.  I’ve played with it a bit, but it turns out to be too cumbersome for me. There were some UI glitches and manipulating items was not that simple as I wanted. Still it might be a valid option for fully Scrum team.

And finally there was Trello. Few friends actually recommended me this and it turns out to be perfect for my needs. It’s simple, intuitive, adorable and it is flying free above the clouds. As a welcome, you get three boards: to do, doing and done. You can quickly add Items, move vertically and horizontally, edit, add categories and make the board public. I’m not going to give you full review, that’s not what I’m here for. But you may want to check article here. The Wired had an article about coolest 7 startups you haven’t heard of, and Trello was one of them.

So, I have a lingering Product Backlog. You may check it out here. The link will be always available from the BookSentry, the main project page.

Huh, that was a long one. In the next episode, I’m going to talk about the environment. Namely the Server and the Database.

p.s. I’m using Wikipedia links a lot. It’s not because I’m a noob. My intent is to give you some quick and neutral overview of the subject at hand. You can get easily to subject’s home page (if it has any) from Wikipedia page for further, official details.


1 Comment

Posted by on August 17, 2014 in Agile, BookSentry


Tags: , , ,

Dramatis Personae

Entry 3, Day 4

Before an application is created, we need people to do that. People assume different roles, and I’ll try to define them today.

I thought, I will be using SCRUM framework, but actually by definition you can’t have SCRUM if you have only one person (unless we are talking split personality or other mental disorder). As you may know, Scrum Master and Product owner cant be the same person because of conflict of interests. However lets forget about that for a moment and take a look:

Client – The guy with money, needs and usually little to no idea how exactly to fulfill those needs with proper software. He wants stuff done quickly, cheaply and with high quality and finds it hard to understand that he has to pick one of those three. Usually does nor understand technology and people creating it.

Product Owner – This is the guy that is patient enough to talk to Client without cutting himself. He is able to find out what actually Client needs, what is most important for him and translates this into prioritized User Stories. Then he comes to the Dev Team and tries to explain what needs to be done to make Client happy.

Dev Team – Bunch of guys who talk strangely, gather in circle and sacrifice coffee to summon and control software. At least that’s how it looks like from the Client point of view. Dev Team has all the skills, resources and pizza required to create an Increment – working piece of software that can be thrown at production servers and will not cause a disaster. Or at least not a big one, small to medium seems to be tolerated on most circumstances.

Scrum Master – Invisible ninja who makes sure the other three do not kill each other. Basically knows the Scrum Grimoire by heart and guards the entire process not to go bananas. Should also has a healthy amount of common sense and transfer some of it to relevant party if needed.

So, I am going to be the Client, the Product Owner, the Dev Team and the Scrum Master in one person.

Besides talking (writing) a lot I’ve done a bit of investigation in hosting department. Nothing special.




Posted by on August 5, 2014 in Agile, BookSentry


Tags: , , , ,