Building an Agile Team

Piotr Romanowski

teamowrk_post

“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

Commit

“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

tinypm_slack

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

tinyPM_notification_in_Slack

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 proper tool

Piotr Romanowski

hammer
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 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 highly important rule. If you’re running a project you need to find the best tool that will help you to manage your projects efficiently. It’s also important that ‘the best tool’ that you’ve found should be as simply in use as possible. You don’t want to waste your time to understand how this tools works. Do you? Instead, you want to use it here and now!

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

 

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

 

Taskboard
It is a place closest to a white board on your wall. This is where things get done on a daily basis. You can shape your flow as you like, starting with the three default states 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 like. This is a place where developers rule and we make sure to help them do things fast.

 

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 product into a hierarchical structure, give it more dimensions), use different card colors and feel the power of visual management.

 

Customizable view
Different job may require looking at your data in a different way. When you start your project and plan ahead the 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:

http://www.tinypm.com/features

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.

Success

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!

462550595(1)

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

github-setup

github-url

 

github-setup_service

 

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:

task_1

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:

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

task_2

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.

team


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.

sidebar


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.

csv


PDF Report

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

pdf


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.

Lifecycle

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.

Agility starts with Expectations

Marcin Niebudek

When we first started creating tinyPM, we wanted to build a tool that will help us do some often repeated things, that will help us structure our actions and make it all visible to our clients. We did not create any user’s guide. We assumed that everyone that will start using tinyPM will find elements familiar to agile environment and the only thing we need to do is to make them easy to use.

Why Are We Here

We assumed that a user of agile tool will know what to do with it. But the time passed and agile way of working got into mainstream. Now we often get questions “Where is the user’s guide?” or “I signed up, followed the first steps, but what do I do next?”. Finally “We want to start working agile way and a friend told me to take a look at your tool”. This one actually made me think about this post.

So many people want to be agile these days. That’s great as agility offers great ideas, but the first steps those people take go down to finding a tool that will… Hmm… I think “that will guide them” is what they actually are looking for. If you are such person or if you ever be asked to recommend a tool, please, first think about:

Expectations

If you think about Agile, I’ll give a short recipe or checklist that I would like you to follow.


STEP 0 – Agile Manifesto

This is an ancient paper once created to remind the values and principles that make us all want to be agile. READ IT! I really do mean it. Read the manifesto, but what is more important read the principles. We’ve done a terrible thing once and read only a few first pages of Winston Royce’s Waterfall paper not paying attention to the rest of the document. Please do read the “second page” of Agile Manifesto.


STEP 1 – Ask yourself some questions

  1. What will change after I become more agile? What change do you expect? How your situation will then differ from what you are dealing with right now?
  2. Why am I doing this? What is wrong right now? What areas do you expect to fix?
  3. If you could remove one of your current problems, which one would it be?
  4. Do you see some agile principles that you could follow to remove that single problem?

This will set your expectations. This will help you focus on the right things. Being agile is useless unless you have some expectations towards your current process.


STEP 2 – Experiment

Take the most painful problem and try to find agile solutions or at least try to find out what Agile methods are offering to solve that problem. But start with a problem and expected outcome. You will quickly find out that your first steps lead to a team’s room or to a chat by the coffe machine, not to a web sign-up form. That will come later, probably somewhere around STEP 20 :-)

If you don’t know what to do with an agile web tool, then you’ve probably tried to skip some steps. Unfortunately this will rather slow you down instead of making you more agile and we really want you to succeed!

Go talk with you team mates.