Category Archives: Agile

SCRUM, Agile, process and people

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: , ,

Pay your debts

Episode 41

I’ve seen recently a nice movie based on actual events – the Deepwater Horizon. Aside from being well made and entertaining, the movie had an additional value to me. It was a story of what happens to a project with insufficient tests and short sighted management putting pressure to release unfinished product with monstrous technical debt. It blows up in huge ball of fire.


Technical debt

Ward Cunningham coined the term technical debt while working on financial software. The idea is, that when developing software, you can often go in two directions. You can spend more time and implement the new functionality cleanly, soundly and with respect to existing architecture. If the functionality does not Read the rest of this entry »

1 Comment

Posted by on October 27, 2016 in Agile, Clean Code, Technology



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: , , , ,

Software Craftsman: Professionalism, Pragmatism, Pride

Episode 25

Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships

Software Craftsman:  Professionalism, Pragmatism, Pride by Sandro Mancuso is the second book about the subject I’ve read recently. Thanks to Safari, even before the paperback edition is available on Amazon. Actually I had an occasion to attend the author’s talk on software craftsmanship at last Jax conference, but I’ve chosen in memory data grid which was probably mistake. Or maybe not, since we have everything on You Tube anyway.


The book came thirteen years after the one I’ve talked about earlier. It gives you a bit of history of the whole idea of software craftsmanship, books, articles, conferences, events and things like that. The basic ideas are described in similar way, to give you a good basic understanding, but there is much more.

A lot has happened in past thirteen years. We had an explosion of the whole Agile and Scrum thing popularity. Simultaneously almost no one does Scrum the way it should be done. Some people are at least aware they have ScrumBut (“you know, we have Scrum, but…”), some don’t. Anyway there is quite a lot of material in the book about issues with Agile transformations and what to do with it. There are several archetypes of problematic personalities like The Sceptic, The Evangelist, The Ivory Tower Architect and so on, and tips on how to talk to them to make things better.

A lot of attention is paid to the topic of management and recruitment of software craftsmen. I especially liked examples of good and bad job descriptions and the elaborate logic behind it. Sadly, most recruitment processes are far from being able to attract good programmers. They are done by people who just think in years and acronyms.

Also, importance of technical excellence is discussed. Some people tends to believe, that if they employ Scrum to their project, things will magically fix themselves and everything will be great. Bullshit. If you had mediocre programmers who produced crap, Scrum meeting, roles and artifacts won’t change that. You need to change the way software is written and thought about. Continues integration, tests, refactoring, striving for technical excellence and constant learning. Nothing comes for free, except coffee. If your company does not provide free coffee, leave it immediately.

Important message is, that craftsmen are not paid to work 9 to 5, do what is told them to do and go home. True craftsmen care. They are far more than just coders. They are there to help client achieve their goals. Through coding, motivating, organizing, sharing their knowledge and most importantly striving to make things better and transforming their organizations. They need to talk to their client, and try to understand what is really to be done. Unfortunately many organizations are stuck in previous era and not ready for this. There was a story about project that had a sole goal of bringing code coverage of code debase to 70%. It was off shored to different company, no one explained them any business logic and all the original programmers were to busy to talk. As it turns out, the reason for that is because some manager had a yearly goal, and fulfilling it gets him a bonus. So he fulfilled it blindly. Well, some people just need a high five. In a face. With a chair.


I enjoyed the personal feel of the book. Author presents his American dream story (or British, in that case) of poor kid from Brazil who wanted to be software developer in London. Now he is the founder of London Software Craftsmanship Community. There are a lot of true stories from the trenches, which are lively, convincing and I had a feeling “hey, I had this one too… just like that”. For me it was much more enjoyable than Pete McBreen’s book.

Finally, do not expect that your employer will train you, educate you, buy you books or anything. If he does, that’s great, but this is your responsibility to learn, invest time, money, energy and passion to be good. You own your career. You shouldn’t pursue “career in an organisation”. You should pursue your own career. That’s your life, isn’t it? If organisation’s career map is not aligned to what you want, they way you want, simply quit. Don’t be afraid. Each job is just a step on the long staircase to mastery. Some are longer, some are shorter, lower or higher. Some will lead you down, not up. But it’s everything about the beauty of the journey. It’s not about catching the rabbit, but chasing the rabbit. Have fun!



Posted by on December 7, 2014 in Agile, Books


Tags: ,

Software Craftsmanship: The New Imperative

Episode 23

The book by Pete McBreen is one of the early books on the topic. The analogy of software development and medieval craft were suggested before in The Pragmatic Programmer and earlier articles.

software craftmanship

When I got the book my first thought was “I expected this to be bigger” It has only 180 pages. And font is quite large. And a lot of almost empty pages. But okay, never mind maybe author is very concise.

Classical view on software development comes from software engineering applied to large scientific or government project in sixties and seventies. Those methods are in turn rooted in old school management where knowledge on how to do job well lies in managers heads while workers are not paid to think but to follow an optimal way of doing things. Reality is very different though. It’s the programmers who know how to do their jobs well. And in order to succeed in software project, the key things is to find excellent programmers with reputation and get out of their way when they start doing their job.

Author emphasizes importance of programmers strive for mastery and ability to stand behind their creation and support it. Because ability to deliver well crafted software builds their reputation. In such scenario, developers choose their project carefully as wrong client is recipe for disaster.

Also there is a lot about managing craftsmen. Junior programmers are overpaid while Senior programmers are much underpaid usually. Author states, that it’s much better to have a team of 5 masters and pay them as much as 25 or even 50 juniors, because overhead of coordinating the work is dramatically lower and if each of them delivered successfully many applications before, there is a good chance it will happen again. The product will have much higher quality, will be easier (= cheaper) to maintain.

So what about those poor juniors? Well it’s okay to have few of them, but not majority of them. They should learn not only from seniors but mainly from intermediate developers. And whey the gain some experience, they should pass it along to new joiners.

Managers should get accustomed to deal with subordinates who earns much more than they do, and the dumbest thing you can do to a master programmer is to move him to management because this is the only way to ramp up his grade and payment. If your organization has such a model, it’s probably time to say god bye and find someone smarter.

In general, the book presents a strong parallel to medieval craftsmanship model. There are apprentices, who study for few years to become journeymen. The wander from master to master to learn the craft in humility, gaining reputation and crafting better and better software. Andy finally they become masters if they persist.

It’s not silly to be developer your entire career. That’s what I thought five years ago, but now I see that it may be a good path for entire life. Did you know that an average developer has now only five years of experience? Industry is in deep need of people who are doing it for ten or more years, have vast experience and are willing to share it. Yeah, new frameworks and technologies are sprouting on a daily basis, but a lot of core skills haven’t changed much. If you are ambitious and plan to be developer for longer, this book will make you feel good, that’s for sure. Even though author tends to repeat himself and charges 30 bucks for not that much of a content, I think it’s worth reading. And then dropping on your managers desk.

Currently I’m reading another, much newer book on Software Craftsmanship by Sandro Mancuso, and Pragmatic Programmer is in the queue. I guess I will share some thoughts on them in the future.

Hiccup sharpening sword


Posted by on November 16, 2014 in Agile, Books


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: , , ,

The Approach

Entry 4, Day 6

A lot of work in documentation and social media department. I’ve split the About page into three separate ones and add some content to them, and organize widgets..

But lets get back to the project.

We are going to talk a little about general approach to writing software. There are two basic ideas you can follow:

Big Design Up Front – Spent a lot of time gathering requirements for the entire application, carefully plan the architecture amongst white-bearded gang of architect, proceed to code and then test the application. At the end most of the requirements will be outdated since Client will figure out that he wanted something entirely else. Or go bankrupt in the middle of entire process. You are left with beautifully designed and mostly useless software.

Emergent Design – Also known by some coder as Pile of garbage. Actually this is the case if you do it wrong, because emergent design does not mean that we add and add and add new features without any clue or second thoughts. We add new features incrementally within some short periods of time like two weeks (called Sprints). We land with with business value, and working software, go to the Client and ask, “is this what you wanted?”. If it wasn’t, we have two wasted weeks worst case and a lot of experience. However if the Client is happy, we get back to keyboards, seek for common points and patterns and refactor to shape the application structure. We can do that safely, because we have a suite of automatic tests that will protect us from bugs, do we?

Actually, the way to go depends a bit on situation. Some projects may have a very strict and stable requirements, and it might be efficient to use BDUF at the end. But I thing those are in minority. Most of the time you don’t know what will happen in the future. If you do however have a good vision of how the application will look like, It might help you make better choices and plan a bit in advance, saving here and there. Not an easy task, but who said that software development is easy?

I will go with almost pure Emergent Design, and hope it will not turn into, well.. you know.


Leave a comment

Posted by on August 7, 2014 in Agile, BookSentry



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: , , , ,