My favourite Agile tweets – January 2017

In my opinion it’s a form of art to tweet really deep thoughts in 140 characters. Here is a short list of my favourite Agile tweets from January 2017.


The 5 Agile monkeys


I was lucky to present recently both at Agile Australia and LAST conference in 2016. One of my speeches was a 5 minute lightning talk about the 5 Agile monkeys.

In case you missed it, here is a short summary.

Sometimes we behave like monkeys. We imitate others, we “talk the talk” – even if we don’t really understand the topic. We pretend to be agile, but we are not really. We use nice words like “business value” and “streamlining processes”, but we don’t really understand what our team is working on.

So I collected 5 behaviour patterns that I observed when we pretend to be Agile, but we’re not exactly it.

Why exactly five? Because I had 5 minutes to present at the conferences.

  1. The first monkey is the Cowboy monkey. This is the monkey that shoots ad-hoc at everything, claiming that he is agile. no plan, no documentation, forgetting that the manifesto statements are not exclusive (working software over extensive documentation, responding to change over following a plan – these are not exclusive statements, it’s about what we value more). These monkeys are often knowledgeable, so don’t try to blame them. It’s more important to include them in planning the work and make their work visible.
  2. My least favourite monkey is The Dogmankey (nothing to do with a dog, lot more with being dogmatic). We tend to forget that frameworks and methodologies are not legal documents that must be followed by the letter. In my opinion, while these methodologies have been created with the right intention, they are too often being commercialised (to sell courses and certificates) and might be applied dogmatically, to have a false sense of control for stakeholders.
  3. The BullshitMonkey To be honest, sometimes I fall into this category. We tend to overuse words like “customer value”, “prioritisation”, “streamlining business processes”. They’re all true and nice, but worth nothing if you just talk the talk and don’t walk the walk. If you don’t understand what your team is doing, it can become just preaching rather than really understanding how that value is created. Understand what your team is doing, what drives them. Understand what motivates them, understand what are those magic wors (e.g. refactoring) mean, and how you can help their work.
  4. The Tool Monkey Another quite common monkey, addicted to software tools, prefers processes and tools over individuals and interactions. You’ll hear things like “we have to fill out the system properly” or “everything has to be documented in our knowledge management system”. You see these monkeys using tools all day, generating reports – without talking to anyone and having any clue, what is the customer value and what the team is doing. In moderation using tools is good. They are just like frameworks – they’re there to help you to deliver customer value, but they shouldn’t drive your delivery. Imagine software tools as hammers and screwdrivers. Use a physical wall if you need to draw, have conversations in face-to-face, not comments in a software tool.
  5. Tech-monkey – I love the tech monkeys. They do all the right things, refactor, doing TDD, stabilising platforms. Awesome people. What they forget sometimes is to finish work. They always find new issues to work on and if you’re not careful a simple user story turns into a one year quest.

While we are all monkeys sometimes, always aim to be better and help your team to satisfy the customer through early and continuous delivery of valuable software.

Agile principles: 2. Welcome changing requirements

The second principle of Agile is about welcoming changing requirements, even late in the development.

In every software development change requests will pop up regularly. No one knows exactly how the end-product should look like. Even if you have a quite good picture of what you want, there will be changes and misunderstandings. In the traditional waterfall methodology, change requests will go through a rigorous process and you have to get approval for further funding, changing the timelines. In many organisations you have to complete a change impact assessment, go through the selected regression test cases for the impacted areas and of course document, document and write some more documents.

Changes in an Agile framework have an impact as well. But thankfully, you always have a choice.

In the environment I am working currently, we run inception workshops before the project work actually starts. And at this workshop we create a trade-off slider, where the business stakeholders define, what is the most and least negotiable item from the list below. Scope, time, quality, budget, user experience (and these items can change as well). Most of the time quality became the least negotiable item and quite often scope was the most negotiable.

If scope is the most negotiable, in the event of a new change popping up we prioritise the new story and if it represents high business value, we remove the story with the lowest business value from the scope. We still implement what’s most important for the business and remain within the expected time-frame and budget.

On the other hand, if scope is the least negotiable (which I haven’t seen and would challenge unless it’s an airplane design :-)), you would expect increase in budget and time (and the impact would be same as in Waterfall). However, even in this situation the work would be picked from the backlog based on the business value, ensuring that the most valuable stories are delivered quickly.

In the projects I worked in, there were always changes – but in my experience in an Agile framework it’s much better to deal with them.

Agile principles: 8. Motivated and trusted individuals

8. Projects are based around motivated individuals, who should be trusted

This is one of my favourite principles. There are two points that I would like to elaborate. The first is the word “trusted“. Giving trust can make wonder. As Ernest Hemingway said: “The best way to find out if you can trust somebody is to trust them.” My advice is to give trust first. I believe that people will return the favour. 

Motivated individuals

Motivation is a key to success. While this is a common sense statement, probably everyone has had the experience of not being motivated. I know I have. I worked at a large Hungarian bank, preparing system design documentation retrospectively in case there was an audit, so they can show that the bank has done their due dilligence. I knew it doesn’t matter what is the quality of the document and once I created, it will be sitting on a shelf forever. Obviously I wasn’t very motivated and while I did everything I could do to make it a usable document, I am sure I could have done a lot better job. If you want people to deliver excellent work, you want them to be motivated. But motivating people is not an easy task.

Motivating speeches can have short term positive effect, but you don’t want to rely only on pep-talks and heart-warming speeches. There are a number of different grouping methods explaining how researchers analyse this topic. One of my favourite introduction is a video on Dr. Jason Fox’s website. Check out the website or go to The key to successful motivation is … (drum-roll) … doing the work. And it’s true.

I’ve done a bit of research with a project team. I’ve introduced many good/stupid ideas to motivate the team. I had a thank-you box, I facilitated team lunches and coffees, I’ve asked individually and in group sessions how they are feeling, and to my surprise the number one thing that made people happy was getting work done. And the most frustration came from occasions where we were not able to progress due to administrative / political hurdles.

If you are in a management position, make sure the team members have meaningful work that consistently progresses, which often leads to a greater sense of achievement. Honest recognition is important as well.

Let me know your thoughts. What are the things that keep you motivated?


Agile principles: 7. Face-to-face conversation

I’ve decided to write about the 12 Agile principles in no particular order. I can only write about my experience, but hopefully it will still provide useful information for you.

The 7th Agile principle is: Face-to-face communication is the best form of communication (co-location).

In my opinion and experience, this is a very important principle for any project (whether it’s agile or traditional). Even better, this principle is a very good guideline for almost any area in life.

But let’s focus on work. Probably you’ve had the experience of wasting time on e-mails. I know that in one of my previous workplaces we wasted tremendous effort on  writing complicated e-mails and reports to protect our backsides. To be sure that we don’t miss out anyone, we copied in managers and the managers’ managers. Obviously while those e-mails looked very professional, most of the time they ended up in the Trash folder. And I can’t say I was very proud of writing daily status reports that no one really read, but forwarded onto other managers… But that was the process and I had to send out those e-mails to get the daily contract rate and to be a “good worker” .

I don’t hate e-mails. There are exceptions and there is a place for e-mails. You wouldn’t commit to a contract verbally (always subject to interpretation). You will need to send out an e-mail for training participants with information. But when you send out an e-mail, you should ask yourself: Is this the best channel of communication?

Let’s jump to the telephone conversations. While telephone calls are verbal, you miss a lot of non-verbal elements if you can’t see the other person. And we all know, that non-verbal signs carry the most significant messages. If you have people offshore, video conferences might be a suitable solution. I’ve seen a workplace where the two teams could see each other through a webcam and a large screen all day. It requires significant investment and maturity. People need to understand and accept that someone on the other side can see every move that they are making.

Let’s not forget about social media. When the Agile manifesto was written, social media was not a buzzword yet. There is useful application for tools like Chatter, Twitter. While they are not replacement for a conversation, they are there to share short updates and knowledge.

And of course there are instances when you burn yourself. It might happen that you talk to a person one day and the next day that person denies that the discussion ever happened. Trust can make a difference.

As a summary, I believe this is a key principle and I recommend to ask yourself when starting a new e-mail: Would it have a better outcome if I’d talk to that person face-to-face?

I welcome any comments to my thoughts, either here or if you see me at a Melbourne meetup, face-to-face…

Selling or sharing

Agile, Lean, Kanban, SCRUM, Continuous delivery have become buzzwords in the last few years. As always, when there is value behind an idea, people jump on the bandwagon and advertise themselves as experts in those ideas.

There are sales guys (no offence to people working in sales), who understand the idea and re-brand their services and products using the Agile principles as selling points. They know that customers like to hear certain buzzwords (collaboration, lean, customer value, empowerment, etc.) and they sell with these words without knowing much or without being interested in the outcome. But there are more people, full of enthusiasm for Agile, that want to share their experience and make organisations more successful.

And that enthusiasm is what I experienced at the LAST conference. Most of the presentations I attended were truly about sharing knowledge, pitching new ideas, emphasising lean/agile values. They were not about selling X software products or about offering coaching services. The people I met showed true interest. The whole conference had a “community gathering” feeling about it. The sponsors (like Elabor8) truly believe that they can “optimise the value of technology investment” or “align strategy and development so that releases deliver the most valuable features in your roadmap”.

One of the many reasons I like to be part of the Agile community in Melbourne, because it’s not about selling, it’s about sharing.

Why do you like to keep in touch with the people promoting agile / lean / etc. practices?

Yikes! Spikes!

I’ve started my first project as an SCRUM master / iteration manager. With the help of lot of experienced people I ran an inception workshop (read more in an upcoming article) and started the solution selection with the team. However we had a lot of tasks on our wall that were not really providing business value. We had to gather information on certain solutions and prepare for the actual implementation. While we tried to write the cards in the usual “As a … I want to … So that…” format, the stories didn’t directly add business value (“As a user I want to know what is the best hardware so that I can achieve the business goals” just doesn’t cut it).

Then after reading some Agile literature, realised that we are creating spikes. Nothing wrong with them, they are necessary for projects (especially at the start). Here are a few definitions of spikes from the Internet:

“Spikes are a type of story that are used for activities such as research, design, exploration and even prototyping. The purpose of a spike is to gain the knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate.” – Scaled Agile Framework,

“A story or task aimed at answering a question or gathering information, rather than at producing shippable product. Sometimes a user story is generated that cannot be estimated until the development team does some actual work to resolve a technical question or a design problem. The solution is to create a “spike,” which is a story whose purpose is to provide the answer or solution. Like any other story or task, the spike is then given an estimate and included in the sprint backlog.” – The Agile Dictionary,

However, a technical task is not a spike – although quite often handled as one. Converting data or preparing an interface or developing a code will add business value – even if often it is not as clear.

What is your opinion: where does a task like ‘setting up infrastructure’ belong? Is it a task for a user story? Is it a spike? Should an activity like this be on the wall? Would like to hear your thoughts.


While we have external Agile coaches at our company, I was curious what other companies and people do. With the company we visited REA Group and MYOB to learn about their Agile practices and transformation. As a private person I joined LinkedIn groups, purchased a few books (see in upcoming posts), watched YouTube videos and recently started going to Meetups.

Meetups provide fantastic opportunity for networking and connecting to people interested in a certain subject. There are heaps of meetups at, you just need to register and set the location that you’re interested in. Search for a topic (let’s say #Agile) and you’ll find a number of interesting groups. I’ve joined a few of them and started going to the meetings. There are some that I have enjoyed and a few that I will probably skip in the future. The format of the meetups are different. There are some that run in a coffee club format, some have a certain topic for each meeting with someone presenting. I encourage trying a few and go to the ones where you can add the most value and where you can learn and grow.

There are also interesting conferences coming up. Agile Australia is one that unfortunately can’t attend it this year, but most likely it will be quite interesting (it has a price tag though). LAST and Dare conferences definitely sound interesting and hopefully I can make it to them.

Which one is your favourite meetup?

If you are in Melbourne (Au), I recommend these ones:

And will try a few more in the upcoming months…

The twelve principles

There are lots of different Agile implementations and I quite often struggle with whom should I listen to. The simple method that I am trying to follow is to think about the Agile Manifesto’s twelve principle. If something is related to that 12 points, it’s Agile. If we prepare documentations, have lengthy meeting and don’t focus on working software, it’s not agile.

The Agile Manifesto is based on the following twelve principles (source: Wikipedia):

  1. Customer satisfaction by rapid delivery of useful software
  2. Welcome changing requirements, even late in development
  3. Working software is delivered frequently (weeks rather than months)
  4. Working software is the principal measure of progress
  5. Sustainable development, able to maintain a constant pace
  6. Close, daily cooperation between business people and developers
  7. Face-to-face conversation is the best form of communication (co-location)
  8. Projects are built around motivated individuals, who should be trusted
  9. Continuous attention to technical excellence and good design
  10. Simplicity—the art of maximizing the amount of work not done—is essential
  11. Self-organizing teams
  12. Regular adaptation to changing circumstances

While there are lots of Agile frameworks, I will try not to lose focus in the huge mass of acronyms and always focus on customer satisfaction, motivated individuals and working software.