M.H. Jongerius

Design patterns: command pattern

Thu, 02 May 2013 21:39:00 +0200

In our pizza sessions we are currently looking at a variety of design patterns. I am a big fan of using design patterns because they provide best practices for a lot of software development issues. One of the simplest but very powerful design patterns is the command pattern. Basically the only thing the pattern dictates is that there is a command interface (or base class) that states that objects implementing the interface should have an execute method. The great thing about this pattern is that now the object that needs something to be done doesn’t have to know anything about the object performing the action. All it needs to know is that there is going to be an execute method.

Endless variety
You can really use your imagination when using this pattern. In the example image I’ve added an abstract base class to the pattern so you could add common stuff like, writing to a log, to this base class. You could also add undo actions to the pattern.

Don’t over do it
When using this pattern you’re hiding most of the implementation of the command from the outside world and this is a good thing. However it’s easy to over do it and create horrific classes that fire a cascade of actions on execution. Keep in mind that every command should only have a single responsibility. Keep your classes small and easy to unit test.

I’d like to thank my colleague Jeroen Wernsen for organizing this Pizza session and walking the team through a couple of implementations of this design pattern.

How we organized nearshoring

Mon, 15 Apr 2013 17:35:00 +0200

In January of 2013 we’ve started a team of software developers in Minsk. We did this because we needed more flexibility when it comes to up scaling our workforce and found it difficult to find good developers in the Netherlands.

Our vision on near shoring
We want to make sure there is no distance between our business and the development team. I personally do not believe in having business development in the Netherlands and the development teams in another country. So what did we do? We decided to build co-located teams where every team consists of people in our company in Tilburg and people located in Minsk. This way the distance is put inside of the team and not between the business and the team.

Our experience so far
Off course success highly depends on the individuals working in the teams and also we have not been working this way for long enough to call it a success. However, what I can say is that working together with developers in Minsk has a 100% better then I expected at first.

I do backlog grooming together, have retrospectives and planning meetings, do a daily stand up and even though there is a 2000 km distance. I don’t experience huge problems because of that.

Short summary on how we work
Our near shoring team consists of two back-end developers and a front-end developer in Minsk we supplemented this team with one of our lead developers / architects and a front-end developer and tester on our side. We work co-located most of the time but it is required to schedule business trips regularly.

Great video on Agile Product Ownership

Fri, 12 Apr 2013 17:47:30 +0200

Great video on Agile Product Ownership

Organize pizza sessions

Sun, 24 Mar 2013 16:54:00 +0100

As a team we decided a year ago to organize what we call “pizza sessions”. They are 2 hour sessions after work hours for training, coding dojo’s or whatever else we would like to do to become better software developers.

Our recent sessions have been about development patterns. In the upcoming blogposts I will make shorts summaries on the subjects because I believe it’s very important for any developer to know and understand software development patterns. After all why would you break your head over something if someone else already found answers.

If your team also organizes sessions like this I would like to encourage you to share them.

Does agility still need control gates?

Tue, 02 Oct 2012 08:48:40 +0200

I’m very enthusiastic about Agile software development. I believe it fits the way people want to work and it brings out the best in people. There is one downside though: every now and again I run into people who oppose everything that could loosely be associated with “old-style” project management.

I think this is a bad thing. For one because these “old” techniques were also devised by intelligent people who probably had the best interest of software development in mind. But more importantly because you miss out on an opportunity to learn.

One of these fields is whether you should have control gates in agile projects:

In project management, a control gate may be viewed as a point in time when the system development effort will be evaluated and when management will determine whether the project should continue as is, change direction or be discontinued.

If you don’t believe in projects anymore you may also think control gates shouldn’t be used because you can change easily after every sprint. The reality however is that agility on an enterprise level is not nearly as “agile” as for small start-ups.

In my opinion, when scaling agile to an enterprise level, you still need to build in control gates in your processes. The sprint-to-sprint feedback simply won’t be enough when working with multiple teams on a product portfolio.

“By the way: I don’t think agile == scrum, that’s just the framework we’re using so I tend to use it in my examples.”

Related articles:

The heart of agility

Having an online review meeting

Rant on seniority

The secret to prospering companies

Stop messing up scrum teams!

FedEx days - an absolute must

4 reasons to give agility a try

Pleas feel free to comment!

The heart of Agility

Fri, 21 Sep 2012 14:38:00 +0200

What’s the essence of Agility? Sure we have the Agile manifesto, but what does it mean for a developer? I’m sorry to say, but too often I hear people say: “hey listen we do scrum, so we are Agile”.

OK, so what exactly is it what you do then? “We do, stand-ups and retrospectives and we have a scrum master and a product owner and last but not least we have short delivery cycles.” All of that is great, but does it make you agile? Or are you just exceptionally good at following the rules and implementing a process.

I have just discovered a funny thing on the internet. If you Google for images on “passionate about software development” guess what you get? Faces of people and only faces of people. No companies, no procedures, no rules, just people who are passionate about creating great software.

For me this is the heart of Agility. People who are passionate about software development. People who know the value of procedures and rules but have the courage to throw everything out the door, just to get a job done. People who feel responsible for their work. People who are not afraid of the uncertain, but embrace it. People who are willing to step up to the plate and truly make a difference.

And for a company to be Agile you need to enable people to behave and act with this passion.

Related articles:

Having an online review meeting

Rant on seniority

The secret to prospering companies

Stop messing up scrum teams!

FedEx days - an absolute must

4 reasons to give agility a try

Pleas feel free to comment!

A PO's Perspective: Lose the negativity

Tue, 28 Aug 2012 10:35:00 +0200

A PO's Perspective: Lose the negativity:

jcmarsh:

I read an article recently which talked about the impact listening to negativity has on you. I firmly believe in order to succeed you must surround yourself with people who have a positive influence on you.

If you wake up in the morning and are immediately slammed with negativity, you are bound…

On architecture in an agile environment

Sat, 04 Aug 2012 20:29:00 +0200

Although there is no agreement on the precise definition of the term “software architecture”, I believe it is one of the most essential disciplines in successful software development. It is also one of the most difficult ones, especially in an Agile environment. After all, how do you design a system if you are delivering working software every sprint.

My idea on agile architecture
First and foremost I believe one of the keys to successful agile development is a solid strategy. Architecture should always come from a long term vision of your company. I like the 4+1 architectural view model by Philippe Kruchten, although the model did not originate in Agile practices. The model helps us as agile teams to think about architecture on several levels:

A logical view: concerned with the functionality the system provides to end-users.

A development view: using the programmers perspective and describing system components.

A process view: explaining the dynamics of the system also thinking about the various “ilities” like scalability and usability.

A physical view: concerned with how the system will be deployed and will function from an engineer’s point of view.

And last but not least scenario’s to connect all the views together.

I like this model because it can help you to ask the right questions when you’re adding functionality to your software and it broadens the definition of architecture to more than just the developers perspective.

Emergent architecture
As your building software sprint-by-sprint the 4+1 model can help you make architectural decisions per sprint. If this is combined with a solid strategy and vision it can help you build the architecture you need bit by bit and let it emerge.

Would you like to discuss Agile architecture further?
On Thursday the 23th of August Prowareness, one of the leading companies on Agile software development in the Netherlands, will be hosting it’s first Mastering Agile Development* session on the topic of Emergent Architecture. Together with Jeroen van Menen and Robert van Vark I would love to envite you to be there and share your experience.

Click here for more info and to subscribe (Dutch event)

* the “mastering agile development” sessions are organized by and for agile developers, testers, architects and business analysts working in an agile environment.

Related articles:

TDD is not about testing

Rant on seniority

The secret to prospering companies

Stop messing up scrum teams!

FedEx days - an absolute must

4 reasons to give agility a try

Please feel free to comment!

Do you assign storypoints to bugfixes?

Mon, 16 Jul 2012 21:00:00 +0200

This is a question that can cause quite some discussion when talking to fellow agile developers. Before giving you my view on using storypoints for bugfixes let’s first make sure we have the same viewpoint when it comes to bug fixes.

When I’m talking about bug fixes, I do not mean work that came out of a sprint and was NOT DONE. Stories that go into a sprint should be DONE DONE by the end and thus not contain any known bugs. When I’m talking about bugs I mean the unknown problems that can occur in the software and may or may not have anything to do with any of the stories.

So what is this discussion about…
Usually it comes down to how a team views story points. Very often I find developers see story points as some kind of scoring mechanism: the more story points finished at the end of the sprint, the better the performance. If this is the case, it is more likely developers want to assign story points to just about anything including bug fixes. After all the bug fix improves the product and therefore is worth points.

What is my view on velocity and storypoints
In my opinion story points are not a measurement of value delivered and are also not a measurement of performance at the end of the sprint. I try very hard to keep my developers from the “scoring points” mode. I want them to take ownership of the product, not to be scoring points.

So what do I use velocity for? For me velocity only serves one purpose: to try to make a prognosis on how long it will take us to deliver something. Some may say use should not do estimation at all, and even though I would love to skip estimations all together, the IT team is not the only team in the company and other teams need to have an estimate on when a feature will be delivered for them to plan their work.

If velocity’s only purpose is to make estimates everything that doesn’t have anything to do with your initial estimate should not have story points. If you would give story points to bug fixes your velocity would increase, but your accuracy of estimation would decrease. So I don’t give story points to bug fixes.

(I do give story points to changes in scope by the way)

Feel free to share your thoughts and comment on this article.

Related articles:

Prioritization and value estimation

Using the product vision board by Roman Pichler

How to inventory the top product wishes

Idea for a brainstorm stakeholder session

Agile strategy session

A PO's Perspective: Visualization

Wed, 04 Jul 2012 19:51:00 +0200

A PO's Perspective: Visualization:

jcmarsh:

We hear a lot at TLC about the art of “failing well.” This post is about a milestone we had and how we have turned it into a huge learning experience. We release new features, functionality and bug fixes in what has historically been referred to as a patch, but we now call it a Release. Over…

Nice story from the trenches: read more

Planning for Failure: The Problem with Using Hours for Estimates

Fri, 29 Jun 2012 14:56:00 +0200

Planning for Failure: The Problem with Using Hours for Estimates:

planningforfailure:

I was recently asked my opinion on using hours and days for estimates instead of story points for stories in a sprint.

Usually when I ask most organizations why they want to use hours instead of points I get two responses.

It’s what we’ve always done.

We want to be able to measure how…

Read the whole article

TDD is not about testing

Fri, 01 Jun 2012 15:16:00 +0200

I have been working on my TDD skills the last couple of months. When I discuss the use of TDD with colleagues it strikes me that many times someone questions what the use of a given test is.

When for example I would be making a “person” object and this person should have a name. I would write a little test that could look like this:

// GIVEN
Person person = new Person();
string name = ”Menno”;

// WHEN
person.Name = name;

// THEN
Assert.AreEqual(person.Name, name);

When I don’t need any specific business logic for the property “Name” I could make this an auto property like so:

public string Name { get; set; }

Now here comes the catch: a lot of developers would now argue that testing an auto property has no apparent use. But TDD is NOT about testing. This way of thinking may be logical when you write tests after you write code, but in TDD the main purpose of the test is not to test the code (there is no code yet).

For me there are two major reasons for doing TDD:

TDD helps me to think about design before I start hacking up code. This is extremely important because the craft of creating great software is not in getting the code to work (I can write pretty crappy working code) but to create easy to understand and maintainable code.

TDD is my way of documenting my code for future developers. At this moment “name” may be an auto property but future developers may very well want to add business logic to this property and the test at least lets them know what behavior I was expecting.

Related articles:

Rant on seniority

The secret to prospering companies

Stop messing up scrum teams!

FedEx days - an absolute must

4 reasons to give agility a try

Pleas feel free to comment!

Having an online review meeting

Fri, 11 May 2012 10:00:00 +0200

At the end of every two week sprint, as all scrum teams do, we have a review meeting. Most of the time involving the internal stakeholders for such a meeting wasn’t a big problem. If they are in the office, they usually are willing to give us an hour of their time.

My goal however, is to also involve our customers in the review sessions. Our software is mostly used in big companies and the representative of those companies is already involved in the development of our software. For this person to come to the review meetings was a problem though because it’s a one hour meeting at most and the travel time will often be much more than one hour.

For this reason I’ve started to use online meeting tools so that our customers can be actively involved, not only in prioritizing the road-map, but also in our sprint to sprint delivery process. This serves two main purposes:

First of all it gives us great feedback.

Second, involvement also means the customer has greater understanding of what we’re building and the reason we have to make certain choices.

All in all I’m enthusiastic about this addition to our review meetings and I would definitively advise you to give it a try.

Related articles:

The secret to prospering companies

Stop messing up scrum teams!

Using scum in project

FedEx days - an absolute must

4 reasons to give agility a try

Pleas feel free to comment!

"I’ve combined all the blog posts on our product backlog wall in to a single white paper on..."

Sun, 22 Apr 2012 17:20:00 +0200

“I’ve combined all the blog posts on our product backlog wall in to a single white paper on visualization and scrum. Feel free to download and share it.”

- Download the document

Rant on seniority

Mon, 09 Apr 2012 11:40:00 +0200

I’ve been working in IT as a developer and currently CTO for 13 years now. Most companies would consider someone working as a developer for over 13 years a senior developer. But I don’t like to look at myself as a senior developer.

So why don’t I? Am I not good at my job? No, that’s not it. I love my job and actually I think I’m quit good at it. So what’s my problem then?

I believe there is a lack of mastery and passion when it comes to the software development world. To me it seems that anyone who has sat behind a computer for a couple of years gets the title of “senior” developer. At the same time I think software development is a craft that is hard to master. It’s not difficult to write software that kind-of works, but it is very difficult to write good software.

So I’m not a senior yet. I’m just a passionate developer who want’s to learn and get better at my job. I hope you will help me grow and allow me to help you when I can.

Product wall details: maintenance section (4/4)

Fri, 30 Mar 2012 12:26:31 +0200

This is the last post in my series on our product backlog wall. The first posts were about the strategic section, the backlog section of the wall and the scrum section of the wall. This post describes how the team combines maintenance work with doing scrum.

I believe many teams struggle with the unpredictable nature of maintenance when working in scrum sprints. Our company is no exception to this rule and we have found a solution by organizing maintenance using kanban.

How kanban and scrum combine
When planning a sprint we reserve time for the developers to work on kanban. In our case we make sure that a different developer is available to work on maintenance jobs every. This makes sure there is a continues availability to do maintenance throughout the sprint without much interference with development work.

How maintenance gets prioritized
The backlog gets prioritized based on value by the product owner. Maintenance work gets prioritized by our support desk because they have a clear understanding of the type of problems customers have. The support desk doesn’t only prioritize the work but also categorizes the work:

bugs need to be looked at as soon as possible.

tasks will be scheduled.

request for change and/or wishes are forwarded to the product owner to be evaluated and potentially put on the backlog.

How the kanban board works
The kanban board has 5 columns:

The backlog holds all the reported support calls.

The next column works as a prioritized list of work to be picked up by the team.

The in progress shows calls that have been picked up by the team.

The test column contains stories that are ready to be tested internally by the team.

The acceptance column shows stories that have been delivered to the support desk for acceptance testing

What have we learned so far
The combination of scrum and kanban helps us to cope with the unpredictable nature of maintenance work. Although most tasks are small enough to be finished within a day, occasionally a task is to big to be finished by one developer in one day. This is unpractical because we have a different developer working on kanban every day so in practice we let the developer who started, finish the task.

We found out that it was important to determine how we we’re performing on both scrum and kanban work. To do this we introduced a couple of performance indicators to report on on a weekly basis.

Like this post?
Please feel free to give your feedback in a comment.

Related articles:

Product wall details: the scrum section (3/4)

Product wall details: the backlog section (2/4)

Product wall details: strategic section (1/4)

Our new product backlog wall

Prioritization and value estimation

Product wall details: scrum section (3/4)

Sun, 18 Mar 2012 20:31:00 +0100

This is the third post in my series on our product backlog wall. The first two posts were about the strategic section and the backlog section of the wall. This section describes the way the team visualizes our sprints. Our scrum board has 6 sections.

The story section (1)
Our scrum board is a pretty default scrum board with user stories broken up into individual tasks for the team to pick up. As soon as every task is done the story gets placed in the busy column. This means the product owner can test the story on our test environment. Once the story has been approved by the product owner he moves it into the done?? column. The question marks are not there because we’re not sure the story’s done. This column is used so that the next day one of the developers can demonstrate the story to the rest of the team. We call this an in-sprint-done celebration. We do this to motivate the developers but also as an opportunity for some early feedback. After the story has been demonstrated it’s moved to the done!column and the points are burned.

The sprint progress graph (2)
The sprint progress graph shows the amount of story points picked up by the team and is a basic burn-down chart. We don’t burn hours because it can give a false presentation of progress. If you’re working on all stories at the same time you may very well seem to be on progress the entire sprint and at the end deliver no value because all your stories fail (believe me we’ve been there). By focussing on story points it helps us to pick up the top priority story first and then work our way down accordingly.

The team’s definition of done (3)
The definition of done is always prominent on the scrum board. It’s the rules the team has given themselves when delivering stories like functionality should contain unit tests, we either peer review or pair program and other stuff.

Our impediment corner (4)
We actually use this spot on the scrum board for everything that happens during the day that needs to come back in the next standup meeting. We encourage the team members to use this spot on the board and urge everybody to participate in identifying and solving impediments.

The tech debt corner (5)
As a product owner I do not always know exactly how the code looks and if we have created technical debt in the software. I know some teams don’t register technical debt and just fix things without necessarily informing the product owner. I personally like to be involved and now what problems the team encounters. Whenever a team member runs into a piece of code that he thinks should be re-factored or sometimes even rebuild, but it’s not really part of the story he’s working on, he will put it in the tech debt corner. This gives us the opportunity to bring it up during the stand up and if the team agrees I make a story and put it in the backlog so the team can pick it up in a future sprint.

Parked section (6)
We like to push ourselves a little bit and pick up a challenging amount of story points each sprint. Occasionally we don’t get all our stories done in a sprint. If we see that happening, we take a story of lower priority and put it in the parked section. We then pick up that story in the next sprint.

Like this post?
I expect to be writing a fourth post on our maintenance section soon, so keep posted.

Please feel free to give your feedback in a comment.

Related articles:

Product wall details: maintenance section (4/4)

Product wall details: the backlog section (2/4)

Product wall details: strategic section (1/4)

Our new product backlog wall

Prioritization and value estimation

Using the product vision board by Roman Pichler

"Choose a job you love, and you will never have to work a day in your life."

Mon, 27 Feb 2012 18:59:15 +0100

“Choose a job you love, and you will never have to work a day in your life.”

- Confucius (via clogish)

Product wall details: backlog section (2/4)

Sun, 19 Feb 2012 18:13:00 +0100

This is the second post in my series on our product backlog wall. The first post was about the strategic section on the far left of the wall. This section describes the way I visualize the product backlog. This part of the wall consists of 5 sections.

The roadmap
The first column is the roadmap. This column has already been discussed as part of the strategic section of the wall. I only mention it here because it’s the linking pin between the strategy section and the backlog. It shows all the work that is currently on the backlog in epic-format.

Investigate and under investigation
The product backlog starts with in investigate and under investigation section. The investigate section is used by me as a waiting list of new things that we will be breaking down into user stories. The under investigation column is used to visualize all the stories we are working so they will be ready for sprint. User stories in these columns are not ready according to our definition of ready.

Ready for poker
Stories that comply to our definition of ready are ready to be estimated by the team and moved to the column ready for poker. We usually have grooming sessions with the team at least once every sprint and use that time for both grooming the backlog and estimating stories.

Waiting
Stories that are estimated move on to a waiting list (one could argue that this is the actual backlog). They are prioritized by value and ready to go into a release.

Ready for sprint
All the stories that are in the waiting section are ready for sprint. We use this column so the business can define what stories go into the next release. We usually release after every sprint but this is more a business decision than a technical one.

Note at the end
The columns suggest a very linear approach to product development. The reality is that I continually shift stories from one column to another (and sometimes back). The goal is to visualize what we are working on and not to enforce procedures.

Like this post?
I expect to be writing a third post on our scrum section within two weeks, so keep posted.

Please feel free to give your feedback in a comment.

Related articles:

Product wall details: maintenance section (4/4)

Product wall details: scrum section (3/4)

Product wall details: strategic section (1/4)

Our new product backlog wall

Prioritization and value estimation

Using the product vision board by Roman Pichler

How to inventory the top product wishes

Scrum Gallery

Fri, 03 Feb 2012 17:47:00 +0100

agileanarchy:

I stopped using powerpoint slides in my Scrum workshops in 2008, shortly after I had created a deck I was especially happy with—a very visual deck. Rather than discarding the slides I printed them out on card and since then have used these to cover the walls of the training room, creating a “Scrum Walkthrough”. The participants use this as a point of reference throughout the training, and it creates talking points during the breaks. I’m in the process of updating this set, to better reflect my current thinking, but for now they are still active.

Read More