Why agile coaching matters?

Piotr Romanowski


“Coaching is the universal language of change and learning.” – CNN


In our previous post, we’ve provided you with some hints on how to build a good agile team that will work like a well-oiled machine. We agreed that building a team isn’t very easy, but it’s still feasible and necessary in order to achieve extraordinary results.

As a matter of fact, pulling people together and maintaining the team in a good spirit can be even harder. This is the time when agile coaching can give us a helping hand.


Anthony Robins (famous life coach) coined a term CANI –  which is an acronym for Constant And Neverending Improvement.  The key word here is an improvement. Therefore, we cannot say that agile is yet another process – an agile approach is a means of improving everything – c o n s t a n t l y.


Here we have a space for agile coach that can help the team to understand why, what they’re doing really matters, and why the agile way matters.

But what is an Agile Coaching, anyhow?


Agile coaching competency framework
Agile coach should aim to “grow a productive Agile team that thinks for itself rather than relying on you to lay down the agile law”.*

As we can see it’s not about simply showing the right path but rather helping the team to find their own way within an agile environment.


We can boil down the agile coaching to five elements:

Mentoring – a coach is a helping hand that can provide the team with necessary advice when it’s needed. It’s quite critical for a coach to have a wide range of knowledge and experience not only in the scrum methodology. Moreover, agile coach needs to lead by example, simply walk the walk, so to speak. So if a coach wants to teach about agile principles,  he needs to follow the agile rules himself during daily work.

Training – agile coach needs to pass all necessary knowledge and enforce it into practice. It’s not a rocket science, every team is different, made up of various people with different experiences and abilities in acquiring knowledge. That’s why a coach needs to remember to adjust the form of information flow to a particular team.

Management – however not managing people but managing the process itself. As we have agreed – agile is a process of constant improvement.

Coaching – it’s a partnership process, during which a coach supports the client (can be a group or a team) in making the best use of his potential in order to achieve particular goals. How does it get done? By asking proper questions, by understanding the team’s flow and all the habits that come with daily work. A coach should help his client transform to the point where he wants to be.

Assistance – coach needs to facilitate with solving all the issues that will occur somewhere along the line with all his experience and knowledge.


Well, considering the above fact it seems that being agile coach is not a piece of cake. But who said it’s going to be easy anyway? :)

It appears that the hardest part in becoming a good, agile coach is developing all of the earlier mentioned competencies. Agile coach needs to have a wide range of knowledge as well as skills to perform all those roles.


So what skills are important to be developed for agile coaches? As Rachel Davies wrote:

- Working with people: listening, giving feedback, asking questions, building trust and rapport

- Facilitating change: enlisting support, reaching agreement, spreading success, learning from failure

- Systems thinking: seeing the bigger picture, identifying levers for change, communicating danger signals


Benefits from agile coaching

Implementing scrum in an organization is often perceived as a remedy for all the problems that a company suffers from. But (as you may have experienced in your companies) implementing scrum isn’t a very easy task and can entail a lot of other problems.

That’s why agile coach is a must!


So here we have some of the benefits that a company can get from implementing an agile coaching:

- An outside view – coaches bring a new perspective to the organization, team and individuals and they remove intrinsic bias and interpersonal issues.

- New opportunity for improvement – a good coach provides learning and training for the employees and develops their skills

- Facing the problems – agile coaching creates an environment that allows teams to face the difficulties and work on a proper solution instead of sweeping problem under the table.

- Saving time and money – coaches bring both the tried and the new practices and processes to a team and organization, reducing the degree of trial and error commonly found in homegrown experimentations.


One size doesn’t fit all…

Just remember that agile coaching is not a holy grail for all the problems that you might encounter with your team.

“Every technique is working and is not working at the same time”

which means that a technique or a solution that was used for one team can work and, on the other hand, can be useless for another team. It’s all about the context and about people.


Picture (with small changes) courtesy of Brain vector designed by Freepik

Building an Agile Team

Piotr Romanowski


“Teamwork is the secret that make common people achieve an uncommon result.”
Ifeanyi Enoch Onuoha


While working in an agile environment teamwork is a must. As we mentioned in our previous post, almost all software projects are collaborative projects. This is how it works – for instance, if a team doesn’t pull together, people get frustrated. As a result (without a shadow of a doubt) the software they produce will reflect this.

We need to remember about an agile approach that indicates simplicity – it’s all about people and communication. The team needs to use proper tools, be well-managed and last but not least – need to know how to communicate properly. Moreover, in order to achieve uncommon results all team members need to not only work in an efficient way but also need to be a good, strong team that is based on mutual trust.

We can’t forget about yet another very important factor – the team work environment should facilitate an opportunity to develop a team spirit.

So how to build an agile team? For sure, you won’t be surprised if I’ll tell you that it’s not a simple question :)

Anyhow, despite the fact that it can be a really tough task, we can still follow some rules that can help us with creating a good team, that runs like a well-oiled machine. Thankfully, we have some hints for you!


1. Create opportunities and space
In an agile environment meetings like daily stand-ups or retrospectives are a great occasion for people to get to know each other better. Of course, probably the best way to do that is to arrange an integration meeting somewhere outside the company. This will provide, so to speak, a less formal way to pull the team together :) People will share their stories, hobbies and so forth. As the people on the team hear the stories, they get a better insight into a teammate. It may sound like a truism, but it really works!

In “Overcoming the Five Dysfunctions of a Team” Patrick Lencioni proposes a simple, yet very interesting exercise. During a meeting, each team member tells a story about a challenge that they faced in the past. Of course the leader or responsible person that runs this meeting should take care that everybody feels comfortable enough and assure that nobody is forced to share something that is too personal. The aim of such activity is to practice being open with teammates. This creates an opportunity to grow a mutual understanding and empathy.

Why not think about other ways to create a social glue among the team? Have you heard about the principle of work in one room? The whole team tremendously improves communication and makes many previous procedures become unnecessary.

That’s why it’s important for the team to adopt their own space in their specific way. Open space is a really good idea because it’s hard to build an Agile team when people are segregated (like testers are in one room, developers in another etc.). Although there are roles in the team, there is no such thing as a hierarchy.

In an agile way, we can speak about the “whole-team” approach. Such an approach stresses the importance of the team – “all hands on board”! The whole team is focused on delivering high-quality software. This kind of approach entails constant collaboration and communication among the people. Work in one room creates a lot of opportunities to make things happen!

And what if the team (for many reasons) can’t seat in the same place? Well, we will cover this topic later on. So keep on reading :)


Here we go with another idea – why not to think about having lunch together? As Liz Sedley wrote:

“Eat lunch with the team whenever you can. Listening to the team in an informal setting helps you understand team better. You’ll find teams often talk about the problems they’re facing over lunch – in a way they wouldn’t at a retrospective. (…)”


2. Have specified goals
Tony Robins said that “Setting goals is the first step in turning the invisible into the visible”. Spot on Tony! Once we have a great, motivated people we’ll need to set reachable but still challenging goals that give a sense of direction to the team.

This part can also be a tricky one. It goes without saying, that if we set too easy goals to achieve, the whole team will get bored and most probably demotivated soon. However, on the other hand, if objectives will be unattainable and out of reach it can paralyze everybody. That’s not what we want to achieve right?

The key thing is to create goals with accordance to the following rule: Not Too Easy, Not Too Hard. People like to be proud of their work so keep on setting challenging objectives. Let’s focus on building the environment where a team can demonstrate creativity, ingenuity, and team spirit to resolve problems in their own, agile way.

The big goal or the big picture is to create valuable and great software. But what does it mean to set goals in an agile way whatsoever? It’s all about the context!
You’ve probably heard about the SMART rule, haven’t you? It says that goals should be Specific, Measurable, Attainable, Realistic, and Timely.  So it’s a great rule, but sometimes it’s not very sufficient. Keeping in mind that agile is about being flexible and adjusting to a current situation (can be changed if needed) we can use SMART rule and adjust it to our agile approach.


S - Specific:
What do we want to achieve, How do we want to achieve it and Why do you want to achieve it?

- Measurable:
What cannot be measured cannot be managed. How will you know that you’ve reached your goal?


A - Attainable:
The goal should be challenging and encouraging for you to do the hard work.


R - Realistic:
Although the goal should be challenging, it should also be realistic.


- Timely:
When will we achieve this goal?

With regards to what was written before – we can use the SMART rule only when we become aware of the context. What does it mean? It means that sometimes we will have to pick a few criteria that will be important to our current situation. Let’s write it again:
- it’s all about  b e i n g  f l e x i b l e !

Agile goals can easily be modified if need be – changed resources, budget, energy or time.


3. Choose the right tool
Working with a proper tool that meets team expectations is a very important factor. The team should also have some space to explore the new technology and to experiment with new software and solutions that can make daily work much more effective.

A good old team-board helps to keep important things visible and it’s still widely used among a lot of companies. It’s ok to work with a board, but it’s not sufficient. Do we have an easy and quick access to the history of changes using a board? Nope. Can everyone involved in the project can look on the taskboard or backlog from any place any time? Nope.

Nowadays it’s pretty common that people can work in distributed teams all over the world – working remotely. Nonetheless, such teams still have a lot of successes! How do they do that? By using proper tools.

So, as you can see a traditional board that hangs somewhere on the wall in a team room may still leave a lot to be desired. Therefore, the key is to use a smart, agile collaboration tool that is reliable, clearly designed and easy to use. That’s why we’ve created tinyPM:

Lightweight and smart agile collaboration tool with product management, backlog, taskboard, user stories and wiki. Web-based and internationalized.”


 It’s extremely important that the tool you decide to use with your team is ready for customization via opened API. This feature is a must! Just like a wide range of integrations with other tools. You can find a lot of great integrations with tinyPM:

- You can connect it to Slack in order to stay in touch with every change that was made in your project
- Or link tinyPM with your GitHub: When you push your changes to GitHub, it will forward your commit to tinyPM.
- and much much more! Check out all integrations here.


“Coming together is a beginning. Keeping together is progress. Working together is success.” H. Ford
Building a team isn’t an easy task. As a matter of fact, as we’ve already agreed – it can be very tough. Nonetheless, it’s worth to put as much attention and effort to constantly improving your teamwork and increase the team spirit. Despite all hurdles and problems that will follow somewhere along the line, just remember that teamwork is the factor that will help you to win the game.


3 steps to write good commit messages

Piotr Romanowski


“If a thing is worth doing, it’s worth doing well” 


As you may know tinyPM is integrated with such SCM tools like Github, Beanstalk, Bitbucket and Stash. Thanks to this integration you can group all commits in a logical structure that corresponds to your backlog structure in tinyPM.

This is actually an awesome thing because you can easily access not only the history of particular user story, but also its development history.

And indeed, it’s all about communication. Almost all software projects are collaborative team projects. A well written commit message is critical to communicate the context of change to team members. Moreover, later on you can easily check and understand the context without going back to it again and again. This is how you can save your time and resources.

Now, this is not only developer’s or project manager’s dream about having everything in the right order and place. Let’s stop dreaming – it can all be done properly here and now!
There is only one condition – a whole team needs to be willing to write great commit messages. And now it’s time to show you how to do that.

Here are 3 rules to follow:


1. KISS – Keep It Simple Stupid 
A good commit message should be concise and consistent.

If the change is trivial that where explanation is not required, single line is sufficient enough as a commit message.
It should be written in an imperative style like “fix a typo”:

If applied, this commit will fix the typo.


If a commit is more complicated we need to write a subject (in an imperative style) and provide explanation.
Within this explanation, we should focus on describing why this change was made and how it benefitted the project.

It’s very important that a commit should refer to one logical change at a time. What does it mean? It’s not correct to write message like: “fix the filtering bug, the searching bug, and add attachments to the user story”. Here we should create three, separate commits:

fix filtering bug 

fix searching bug

add attachments to user story


2. Use three magic questions to provide sufficient context
Peter Hutterer wrote that good commit message should answer three, fundamental questions:

- Why is it necessary?
Concise description of the reason why a commit needs to be done. What does it fix? What feature does it add? How does it improve performance or reliability?

- How does it address the issue?
For trivial patches this part can be omitted. There should be a high-level description of what the approach was.

- What effects does the patch have?
(In addition to the obvious ones, this may include benchmarks, side effects, etc.)


These three questions will help you to provide all necessary information and context for future reference.


You can easily link commits to tasks or user stories in your tinyPM. Simply include a user story #id in the commit message #512 and the commit will show up on this particular story card:

Add a list of recommended products #512

For more instructions about commit syntax please check tinyPM documentation.


3. Do not use excuses!

We all know that sticking to the rules can be a pain in the neck. However, this is often necessary in order to achieve certain goals. Our goal is to write great commit messages, therefore, we need to adhere to such rules.

And yes, there will be a lot of excuses like: “but it works”, “we didn’t have time” or “I’m the only one working on this” and a dozen of others. Finding excuses is way easier than being consequent. Therefore, we need to think about it in the big picture – think how many benefits we can get.

Just remember that good programmers can be recognized by their legacy. Good commit history will help others to start work on such projects readily without any problems figuring it all out.

This should become a habit that will constantly benefit a whole team in terms of productivity and efficiency as well as a sense of satisfaction.

The last word belongs to Chris Beams: “(…) just think how much time the author is saving fellow and future committers by taking the time to provide this context here and now.”

What happens if you combine and integrate two awesome tools?

Piotr Romanowski


Have you heard about Slack?
No? So you need to catch up. Slack is an awesome platform for team communication – “everything in one place, instantly searchable, available wherever you go“.

It’s really great! You can easily improve your team communication by creating open channels, projects and topics that the whole team shares. What do we love most about Slack?
- splendid search feature
- easy way to attach pictures and other files
- beautiful design
- simplicity

It’s just “everything in one place”!


To provide you with essential value of your work
We’ve integrated tinyPM with Slack! Now, you can check what happens when two awesome tools work together to bring you everything necessary to perform a great job!

This is one of these tiny things that help you to transform your good team into a great team! Now you can stay up to date with every change that was made in tinyPM. This integration will post updates to a channel in Slack whenever a story or task activity occurs. How cool is that? images


That’s why we’ve decided to integrate our tinyPM with Slack – to provide you with essential value of being always aware of what’s going on with your projects. Getting notified about every change will helps you to manage your team and your projects more efficiently.


How to connect your tinyPM with Slack?
It’s quite simple and intuitive. You just need to activate Slack in tinyPM’s settings. You’ll need to create and Incoming Webhook in your Slack:

  • Open Slack
  • Click on the dropdown next to your team name and select Configure integrations
  • Select Incoming WebHooks
  • Copy the Webhook URL to your clipboard


Once you’ve created Incoming WebHook in Slack:

  • Open your tinyPM
  • Go to “Application Settings”
  • Click on Slack integration
  • Paste WebHook URL


That’s it! As simple as that. From here on, working with tinyPM and Slack integration you will save your time, manage your projects way better that before and communicate more efficiently.


Tell us about your feelings with regards to tinyPM and Slack integration. We’re looking forward to receiving your feedback.

Always use a proper tool

Piotr Romanowski

Photo Author: justinbaeder / photo on flickr


“A tool enhances our ability to achieve a certain effect (…). A hammer is good for sinking nails but a poor way to drive screws”
From Don Reinertsen’s “Managing the Design Factory”


There is no need to say how crucial it is to use proper tools in order to achieve specific results. Just like in the above quote, we need to bear in mind that if we use a good – or rather, the best tool, it will “enhance our ability to achieve a certain effect”.

It’s not a rocket science but a very important rule. If you’re running a project you need to find the best tool that will help you manage your projects efficiently. It’s also important that ‘the best tool’ you find should be as simple in use as possible. You don’t want to waste your time to understand how this tool works, do you? Instead, you want to use it here and now!

That’s why we’ve created tinyPM – a simple, intuitive and a smart agile collaboration tool.
Here you can find a sneak peak of some of our great features:


A place where the vision of your product takes shape. TinyPM not only lets you create your backlog but what is more important, it allows you to groom it. Reordering of user stories with a drag and drop feature, sort and filter them. Quickly tag many stories, change their colors. Edit story details through in-line editable fields.


This is a place closest to a white board on your wall. This is where things get done on daily basis. You can shape your flow as you like, starting with three progress statuses we give you. Feel free to add more and take control over your board!
It’s up to you! Move them around, leave comments, assign as many team members as you wish. This is a place where developers rule and we help them seed up their work.


User stories
tinyPM gives you more than just a post-it note to write on. Swarm over user story, discuss it, attach details, tag it (if it’s hard to split a product into hierarchical structure, give it more dimensions), use different card colors and feel the power of visual management.


Customizable view
Different job may require you to look at at your data differently. When you start your project and plan ahead, things look different than when you are in the middle of your work. We understand that and provide you with customizable view options. Choose between cards and tables, change zoom level to hide or show more details. Switch between 1-column and 2-columns view whenever you need.


In order to get all of tinyPM awesome features go to:


Bye, bye Oldie

Paulina Tomczyk

It already is! The new version of documentation in tinyPM. For those who like to wade through the jungle we left the good old one here. The brand new, more civilized edition, equipped with intuitive menus, which we have prepared using Grails, is available here (www.tinypm.com/docs/guide). We changed the design to a more modern, transparent and consistent color.


Fast but not furious

Previous documentation of tinyPM had a one continuous layout. The new one has a division into sections. It’s easier to navigate as well thanks to the added menu, always displayed on the side. The documentation includes a description of:

tinyPM Docs

From Grails with love

The documentation is generated using the standard mechanism of Grails to create the documentation for the application. Check it out here: grails.org/doc/latest/guide/single.html#docengine. We adapted it to the very great needs of tinyPM to work on our own templates and css styles. The result? A completely different look, and underneath the same syntax wiki for quick and easy creation of documentation.

How do you like it? Are there any gaps, lacks or mistaken attacks? :-)

Today about Iteration big and small

Marcin Niebudek

We have already had User Story as most popular tool. But this is not the end. Today about Iterations: the small and big ones, these that are completed and those that are never stopped.

Yes We Can

Iteration is a period of 1 to 4 weeks. During this time Customer needs to decide what is the most important at this moment. 4 weeks is also called the Sprint but we prefer Iteration as it’s stronger option.

Iteration is not only about programming but also about tests and more. Actually tests are run before the programming phase.

We also have to mention about infinite period. In this case Iteration is one, only User Story has to be completed in some period of time and then disappears. In this place another User Story appears. Customer tells about that User Story and if it’s good we start with the new one.

And what do you think about this?

Hot news for GitHub lovers

Paulina Tomczyk

Finally happened! Over 6 million users & over 14 million repositories of GitHub integrated with tinyPM? It’s more than possible now. Imagine product management integrated with the largest code host on the planet. All in one – from vision to implementation. You absolutely have to check it out!


Why should you try it out?

Integration with GitHub allows you and your team to link commits in GitHub with user stories in tinyPM. This carries your team through the latest development work and the whole history of commits for each story. When you push your changes to GitHub, it will forward your commit to tinyPM offhand. By including a special text in the commit message you can indicate whether this commit is related to a user story or task in tinyPM.

Stay up to date and tie your commits easily to user stories

To enable GitHub integration with tinyPM just activate tinyPM Service in your GitHub repository:

  • In GitHub open a repo you manage and click on Settings
  • Select Webhooks & Services
  • Click Add service and select tinyPM from the available services
  • Add your URL – copy it from the “Application Settings” page in your tinyPM






Linking commits to user stories

Simply include a user story #id in the commit message #512 and the commit will show up on this story card.

Example commit message:


Linking commits to tasks

To add a reference link to a commit, just include a label like task:123 in the commit message.

Example commit message:

Move tasks via commit messages

Add a message like completed task:123 and tinyPM will update the task status when you push your commit.

Example commit messages:


Good day & good luck! :-)


Timesheet now available in tinyPM 3.1

Maria Hotloś

We’re very excited to announce that the new timesheet feature is now available in tinyPM 3.1. The timesheet is simple and easy to use. It allows you to log the time spent on tasks and gives you instant access to weekly reports by presenting them in a nice and clean table view. You may check out your tinyPM account right now or read on to learn more.

My timesheet

View and log the time spent on tasks of all of your projects with the new ‘My timesheet’ view.

my timesheet

Navigating your timesheet

Use the arrows to move back and forth through the weeks.

week navigation

Log hours

It’s easy to record how long you spent on a task. Just click the selected cell and change the value instantly. Using <TAB> key you can fill in several cells (days) quickly.

log time

What tasks are contained in the timesheet?

tinyPM knows what tasks you’re working on and displays the appropriate ones. Additionally, the cells are marked with color on days that you’ve been working on a given task.

What about the team?

For an overview of your team activity, just click the ‘Team’ button. You will see a list of people you share the projects with and their summary of hours displayed weekly.


Quick summary

In the sidebar, there is a summary of the current and the previous month – total hours by project and options to export them.


CSV Export

For each project you can download a CSV file, which contains all hours entered by all users during the month. This file you may easily open in your ‘office’ application and convert into your favorite report.


PDF Report

You can also download a ready to print report in a PDF format.


We hope this timesheet makes time tracking easy and fast for you. We’d like to know what you think, as we plan to continue improving it, so the feedback and new ideas are highly welcome.

What is a User Story and Why Should I Care?

Marcin Niebudek

User Story is a most widely used tool in many Agile methods. Sooner or later you will need to work on some of them or you will need to write a few yourself. At first glance the whole idea may look strange. All those agilists tell you about index cards, about putting them on the wall. They organize them into themes, create some strange maps, call some of them epics, etc.

What is a User Story?

Let’s start from the beginning. User story describes part of your requirements or part of whatever you are trying to achieve in general. In software development we got used to some template (but this is just an example):

“As a [user/role] I want a system to have [some functionality] so that I can achieve [some goal].”

For example:

“As a blog author (my role) I want to be able to create categories for my posts (functionality), so that I can organize all the posts that I write into related topics for better reading (the goal / why I need this).”

But also:

“As a doctor (role) I need to have access to a patients health records and history before the patient comes to a hospital for a scheduled visit (process improvement) so that I can prepare a plan and book some procedures and a patient stay shorter (the goal / why I need this)”

The goal

Actually a template is not so important and if you like different one, then just use it. The most important is a goal part. A user story should bring some value, otherwise why would you want to do it? When writing a story always think about presenting it to a person mentioned in a story (doing a demo)? How would you show that the goal was achieved? If answering this question is a problem, then you should probably rethink your story.

Big and small stories

We usually tell that a story should fit into an index card or a post-it note. The point is not to put too much detail in a single story, but it’s not a level of detail that matters. It’s about story complexity and the expected amount of work required to be done. You should be able to complete a story in some reasonable time. If you work iteratively, then your story should fit into iteration. If you measure cycle time, then the best amount of work put in a single story would fit more or less in that time frame.

Does it mean a story cannot be bigger. No, not at all. Sometimes you will have just a raw idea about what needs to be done. Your story may initially be just called “Customer service improvement”. We will call it an epic. This story will get more details over time. You will split it into smaller stories that can actually be implemented.


A story have its own lifecycle. It lands in your backlog as an epic, then it gets some details and becomes a set of stories that we can call ready. This is time to start implementing them. They will now go from to do to completed through some various states (depending on your process). There is one more important step…

A story needs to be accepted. This is when you present the outcomes of your work. You will verify if that story meets the set goal. If not, then it will require some more work (which means it will get rejected), otherwise it’s done.

Themes and story mapping

If you are dealing with a complex product or service then you may have a lot of stories to deal with. Having a large backlog is in my opinion a bad idea in general (and I will write a bout it in a few days) but if you do have such a backlog then it’s a good idea to group stories in themes. Themes will usually evolve from groups of epics.

There is also a very useful practice called story mapping. It’s out of scope of this post and I encourage you to read more about it at Jeff Patton’s blog.

What to do next?

So let’s get back to the main question. Why should you care about stories?

My answer is because they are a powerful tool. I would encourage you to think about user stories even if you do not intend to dive into Agile world. They will give you a good perspective and will help you focus on the right things. If you want to learn more about effectively using stories there is a book I especially like. It’s “User Stories Applied” by Mike Cohn.