Project management tools for Agile projects

This is a post by guest blogger Steward Copper

A few days ago I was attending the IT Project Management Conference and participated in a survey. All the attendants were asked one question: "What project management tool or solution do you use for the Agile projects?" Among the Top-10 Agile tools there were the ones I'd used to manage, plan and track my projects and processes - MS Excel, Pivotal Tracker, Comindware and VersionOne. So, let me share my thoughts and experience of using them for task management, sprint and iteration planning, daily meetings, burn-downcharts creation, project tracking and other Agile techniques.

MS Excel

The tool is a standard part of the MS Office package. The main general advantage of choosing it for your next project is that almost everybody is familiar with it and you don't need to spend time for the team training. It's used by many Agile PMs because it:

 - allows to create a product backlog while listing user stories, placing estimates and deadlines;

 - allows to plan iterations or sprints (it's good to create a template on a specific sheet);

 - allows to group tasks into sprints using a using a standard group tool;

 - allows to add any kind of comments for the tasks, stories and other entities using a standard commenting tool;

- allows to support daily stand-ups while filling a sprint progress data;

- provides very high level of flexibility while drawing graphs including burn-down chart, creating custom reports including digital dashboards and so on.

Excel helps many of us to manage projects but it's not so good for remote teams and big projects. Some managers don't use Excel because it doesn't provide the set of predefined processes.

Pivotal Tracker

The tool was created as a SaaS issue tracking system and evolved into a complex solution to support all the main processes of an Agile project. It's chosen thanks to the following:

- it's developed especially for Agile projects and uses Iterative Management Workflow approach;

- it allows to create iterations or sprints including tasks (tickets) of different priority;



- user-friendly dashboard provides one view of theentire project allowing to see the real time information for all the project stakeholders;

- it's good for the team collaboration including daily stand-up meetings and remote teams management;

- it automatically creates charts, including release burn-down, iteration burn-up, story type breakdown, and historical velocity;

- it is available for the iOS platform (iPhone andiPad) and so on.

The tool is recommended by many Agile evangelists including those using Kanban, Scrum Lean and XP. But it's not the only solution on the market. New solutions appear with new additional features. Comindware is a good example.

Comindware

The tool is little bit more than just an Agile software. It combines collaborative task management with workflow automation capabilities. The main feature that allows Comindware to compete successfully with the other solutions is its 100% flexibility (or better to say agility). Project or process manager may create a specific workflow or edit predefined processes even in the middle of a project. The other interesting features used to manage Agile projects are:

- creating and assigning tasks (auto-generated tasks from workflows andtraditional task lists created manually), setting up their priorities;

- project team collaboration which is very essential while managing remote and virtual teams;

- real time status reports including priority, deadline and other reports that are very helpful during daily stand-ups;

- customizable visual dashboard that is perfectly used not only to create all possible types of charts and graphs but also to provide visual information to project stakeholders;

- portfolio management feature allowing to manage multiple projects and generate aggregated reports;

- easy integration (if necessary) with the other tools like SalesForceCRM and MS Outlook.

The Comindware solution may be used as a cloud-basedservice (more cost-effective option) and as a on-premise software (to get the maximum control). It's really a good solution with plenty of different useful features that go far over just an Agile project management. But for those who feel that it's too flexible and has too many features there is a VersionOne.

VersionOne

The tool is better known as a Scrum project management solution, but thanks to a big amount of functionalities it can be used for all Agile methodologies. I've listed the main reasons why managers prefer VersionOne nowadays:

- it allows to manage multiple projects and iterations at the same time;

- it allows to plan sprints and to manage requirements, user stories and epics using very user-friendly interface (I've even heard that some experts named VersionOne as the tool of the best usability);

- it may be used for the team collaboration (sharing files, ideas and messages);

- it allows to create visual burn-down charts, so as storyboards, trackboards,testboards;

- it may be connected with other tools used in software development projects like CruiseControl, Jira,
Bugzilla, TeamCity and etc. allowing better flexibility;

- it provides almost everything for a good reporting andanalysis because there are more than 50 agile metrics and reports, so as a custom analytics platform.

Instead of a conclusion:

Today we have so many software tools that even a very professional project manager may face a problem of choice. So, while choosing the best solution for your next Agile project don't forget the golden rule: a tool is nothing more than an instrument that has to serve the goals of your project and to help you and the team to be effective. As for me for my current projects I use MS Excel (simple on-site projects and to-do lists) and Comindware (middle-size and big projects, processes, managing remote teams).

Author
Hi, my name’s Steward Copper and I am the owner of Project Management Insights. While working as a project coordinator and BA, I have tried almost all possible PM tools, BA instruments, collaboration programs, including tracker and hr system solutions. I also write for different blogs sharing my knowledge and observations.

How to develop effective professional relationships

We all know how important it is to build effective professional relationships. Relationship management is a very important skill for every professional that wants to get ahead. This article will focus on how effective relationship management helps the CIO to get ahead.

The top IT job is very complex and demanding, effective relationship management enables the CIO to build rapport with his/her peers and will most certainly make the job of managing IT much easier.

Before proceeding, it is important to define what the term "effective professional relationships" means. The CIO should spend most of his time interacting with his peers in order to understand the organization's needs and provide adequate IT solutions. Furthermore, the CIO needs to be able to convince other members of the organization that a particular IT project will deliver positive outcomes to the business. Effective relationship management are the ones that enable the CIO to effectively interactive with every member of the organization in order to enable him to achieve his objectives.

The following points provide useful insights on how to develop effective professional relationships.

Know your company and the people you work with

 

This should go without saying, but it is really important that CIOs know their business. What I find interesting about IT management is how broad the role really is. As an example, a Supply Chain Manager is required to know all about supply chain.He is not meant to know anything about how to operate the email server. However, the IT Manager, the one who wants to do a good job, is required to know not only about IT but also about every other area of the business. Obviously the IT manager is not required to know everything  in detail, however he needs to know enough about every area of the business in order to have systems in place that support the various business processes. I find this quite interesting and is what makes the job so interesting.

As the head of IT you need to know the vision and mission of the organization, the products it sells or the services it provides, how it makes money, how it spends money, the competition, the industry, etc... The list is quite long and varies depending on the nature of the organization. The point here is to know everything you can about your business in order to enable you to be a valuable member of the board and/or the senior management team.

I have heard many IT managers complaining that they don't get a chair in the company board of directors and/or don't have opportunities to participate in strategic meetings. Maybe the reason that happens is because the CEO, CFO and other members of the organization perceive the CIO as only a technical resource. That limits the effectiveness of IT. The CIO needs to not only know the organization but he also needs to show to the other members of the senior management team that he can positively contribute to non-technical discussions.

Build a good track record

 

This really means do what you said you would do. Honor your commitments.  Your peers should be able to trust you. Ensure to deliver on every deadline. If you know you will not be able to get something done speak to everyone involved as soon as you can. People will trust you because you always do what you say.

Having a good track record will help you to build a good reputation and nothing is more important than a good reputation.

Quote your peers whenever you can

 

This is quite powerful. When giving credit to someone, you are giving someone else a good reputation. This is especially powerful if the person is present in the conversation. They will always be thankful to you and are likely to return the favor.

Think about it the other way. If you take someone's idea and quote it as your own, you are actually robbing them a reputation they deserve. Worse still, remember that people talk in organizations and that particular idea you are taking ownership may have already been discussed so others might know whose idea that is. People may pick up on it and it can actually destroy your reputation.

Quoting your peers, positively that is, will go a long way in building rapport with them.

Discuss your concerns directly with the people involved

 

It is very important to raise your concerns with the people that are involved in it. Say for example that you have a concern about a particular business practice related to complaint handling. You will look really bad if you approach your boss, especially if he/she is the CEO. The best option is to organize a meeting and raise it directly with the relevant people and not only raise issues but also propose solutions.

However, it is easy for IT managers to be perceived as nosy and wanting to solve someone's problem, or even worse. You need to be careful about the reasons you are raising the issue and try to make it relevant to IT as well. It is not a good idea to say that complaints are not been handled effectively unless your issue relates to IT and you can provide some sort of solution.

Be professional, speak calmly, accurately and concisely

 

In order to build good, professional relationships, it is important to be professional and consistent at all times. Your emotions should not dictate how you react to an issue. There is nothing worse than knowing that you have to deal with someone but you never know how that person will react because he/she has a reputation of being unstable.

Ensure to always be professional, polite and accurate. Most importantly, do not lie. Others can probably see through you so don't even think about it.

Ask insightful questions and encourage a response

 

There is nothing worse than being in a meeting with someone who keeps on asking irrelevant questions and is always interrupting others before they finish talking. It is annoying and a waste of everyone's time. Make sure you are not the one making those mistakes.

It is impossible to plan for every interaction with your peers, however when attending meetings, ensure that you know thoroughly the topic at hand and only ask meaningful and insighful questions. Don't waste anyone's time.

Listen to what people are saying

 

Have you ever been in a conversation and got the feeling that the other person was just not listening? This is even worse if it happens at work. When talking to someone or participating in a meeting, make the other people you are talking to feel that they are the most important people in the world. Give them your full attention, be interested in what they are saying, value what they are saying even if you think they are wrong.

It is only when you really listen to people that you are able to ask meaningful questions and have positive interactions.

Many other points could be raised on this topic, however the list above provides a good summary on ho to go about building effective professional relationships.

The Good Product Manager vs. The Bad Product Manager

Today I came across the Good Product Manager/Bad Product Manager courtesy lecture at the Stanford university by Ben Horowitz, I believe this post is a classic for product management.

I have summarized Ben's points as follows:

 

 Bad Product Manager

• Always makes lots of excuses.

• A bad product manager is not the product's CEO.

• Lacks in communication skills. Bad product managers don't communicate well with the engineering team and tend to blame them when things go wrong due to bad communication.

• Puts out fires all day and complains that is swamped by questions and interruptions.

• When things go wrong they quickly point out that they predicted they would fail and the "powers of be" didn't do anything about it.

• Bad product managers focus the team on the feature that the competition is building.

• Bad product managers get confused on how to position their products on the market and how to leverage it.

• Bad product managers don't know how to work with the press, they don't manage the press.

• Bad product managers always want to be told what to do.

• Bad product managers don't produce status reports on time and are not disciplined.
  
• Bad product managers don't take responsibility and tend to blame others.

Good Product Manager

• Knows the product, the market and the competition really well.

• Is the CEO of the product.

• Takes responsibility for all aspects off the product.

• Manages himself based on the product's performance on the market.

• Takes responsibility for devising and executing a winning plan.

• Good product managers manage the product team and not every detail of every aspect of everyone's work. He/she knows how to delegate and manage the team effectively.

• Good product managers are focused on strategic decisions, ensuring that the product is flexible and adaptable to a changing business environment.
  
• Good product managers create lots of collateral to support the day-to-day operations of the team. He/she is not swamped by questions about the product and ensure that they are not the only ones that can answer questions about the product.

• Following from the previous point, good product managers equip their team to handle the day to day activities allowing them to focus on strategic topics such as market positioning, timing, etc...

• Good product managers focus the team on revenue and customers,

• Good product managers focus on delivering value to the market place and not on just matching the competition.

• Good product managers think about the story they want published on the press and they manage the press, not the other way around.

• Good product managers are disciplined and produce status reports on time.

The courtesy lecture I read today can be found here.

One skill that is vital for good product management is the ability to build good professional relationships. In this article I explain the importance of building professional relationships in the context of IT Management. The same principles apply to product management, in fact, these principles apply to any profession these days.

Whilst the following articles are not written in the context of product management, the principles apply. As a matter of fact, I believe that many product managers lack good planning and management skills which hinder their ability to really excel in their product management career.

•  Management theory and IT Management Part 1 - Planning
• Management theory and IT Management Part 2 - Organizing
• The effective IT manager, the importance of relationship management

 In essence a good product manager is the CEO of the product, knows how to manage the team, the press and ensures to deliver value to the market place.

What are your experiences in product management, what makes a good product manager in your view?

Effort Estimation in Agile Software Development - Applying the Pert Weighted Average formula - Part 2

Back in May 2010, I posted an article entitled Effort Estimation in Agile Software Development - Applying the Pert Weighted Average formula, which has been one of the most popular articles on this blog.

Amongst the feedback received there were many requests asking me to provide more details on how to devise the numbers to apply on the formula. This article expands on the topic by explaining my way of coming up with the numbers for the optimistic, pessimistic and realistic components of the Pert Weighted Average formula.

As explained here, the I use the following formula to estimate the duration to develop each user story that make up an iteration: (Optimistic + (4 * Realistic) + Pessimistic) / 6 .

How to apply the formula

Optimistic - I ask each developer to provide me with an estimation of how long it will take to complete each story they will work on. This is the number that I use for the optimistic component.

To estimate the other components of the formula I use a combination of grading user stories by size and complexity as outlined in the first article. However it is not as simple as that.

I don't see estimation as an exact science and therefore blindly applying a formula will not work under all circumstances. However, the formula does provide me with a consistent estimation procedure that has worked for at least 10 years now.

Another variable that I use in estimating the development effort is my team's velocity. I have a detailed record of the team's velocity recorded against functionality deployed to production. This helps me to compare actual duration of completed user stories against the effort that was originally estimated and use it as a basis to estimate the effort to develop stories that are similar in size and complexity ratings.

So here is how I devise the numbers for the rest of the formula.

Realistic - I search TFS (Team Foundation Server) for completed stories with similar size and complexity ratings and take the actual time that it took to develop it as the realistic component of the formula. 

Pessimistic - It is hard to estimate what a pessimistic duration would be because of many different variables that come into play such as risks associated with the particular piece of functionality, complexity, developer  experience and many other variables. I have met some development managers that double the duration estimated as the realistic and use it as the pessimistic. I don't blindly assign a number to it, I try to take everything into consideration in order to come up with an estimation that makes sense.

I don't think that there is a formula that you can blindly take to estimate software development effort. It is not as simple as that as there are many components that come into play in effort estimation, project management and software development.

What makes a good software developer?

Today at work I started to do some performance reviews. As I prepared the review papers  I started thinking about what makes me rate one developer higher than another.

So the question really is, what makes a good software developer? There are certainly many answers to this question and viewpoints will vary greatly. I don't think there is a definitive answer as the definition of "good" will change depending o what you are trying to achieve.

The following sections provide a high level summary of my thoughts on this very interesting topic.

Technical Skills

Technical skills are definitely very important, however I think that it is overrated. Attitude is far more important than technical skills. More on that later.

Possessing well developed technical skills enables developers to complete their tasks faster and therefore it has the potential to make them more efficient. In the past 2 or 3 years I have introduced new technologies in my current organization. Those projects didn't come without challenges, there were some rough days and times of low productivity. The developers with more advanced technical skills were able to understand those technologies and become more productive faster than the others. The real good developers became mentors to the other ones, without making them feel bad.

Attitude

Attitude is by far one of the most important skills a developer can have.

We all have different strengths and weaknesses, we can't all be technical geniuses or specialists in every single area of software development. When a developer faces a technical challenge and "hits the wall", no matter how good he/she is technically, attitude will determine the outcome. A good attitude and the ability to stick with it until the issue is resolved is key in this situation.

What I find particularly annoying is a developer that lacks these skills and as soon as there is an issue he/she immediately starts to ask the other developers without even researching the web or the team's wiki. Having said that, when facing technical challenges, there is a line when one needs to decide to stop researching and ask for help. I don't like to see developers stuck and not ask for help. Once research is done and a solution is not found, there is nothing wrong with putting your hand up and asking for help.

Business Knowledge

Business knowledge is also very important to enable a developer to work productively. Whether you work for an internal IT team or for a development house, having good domain knowledge enables developers to better participate in design meetings and to decide what delivers real value.

The time has past when developers sit in the corner and writes code according to the specs without asking questions or participating in solution architecture and other related tasks. We are all doing agile these days and moving to self-managed teams. Against what many people believe, implementing agile and self management is actually very hard. In order to have self managed teams you need developers that understand the business and are able to have meaningful discussions without project stakeholders. Without domain knowledge this is practically impossible.

Furthermore, well developed business knowledge enables developers to question the completeness and accuracy of user stories, either before or during development.

Lack of business logic is actually very dangerous because the developer does not actually know what it is that is being developed and what value it delivers to the business.

I would say that domain knowledge and attitude are some of the most important skills a good developer needs to have.

Openness for discussion

There are many different ways to address a particular technical issue or to develop a new function item. In my team we have daily stand up meetings and longer design/review meetings depending on what is going on.

Every so often we hold meetings to discuss the architecture and/or the best technical solution for a particular issue or functional item. During these meetings we discuss what the is the best solution and we move on to implement it without wasting too much time. I find very entertaining to see the developers argue to have their opinions or solution implemented. My own entertainment aside, these discussions are very important for the ultimate quality of our work because nobody knows everything, it is when we all sit around and workshop ideas that the best solutions are implemented.

I need to be careful and manage these meetings very well. Once we agree on a solution I quickly move on to the next topic or I end the meeting. The overall process works well, it has increased team cohesion and even the quietest developer starts to participate which is a bonus to everyone.

It is a win-win situation for me.

Appetite for new knowledge

IT is always changing. New technologies are often released to the market, new frameworks and methodologies are reviewed and update. It never stops. In order to keep up with it, developers need to be curious and have a appetite for new knowledge. You never really graduate from uni if you work in IT.

I could keep on going and identifying many other skills like knowing your tool set and many others, however I will stop here because I think that, in broad terms, I have touched on what really makes a good software developer.

I find really amazing that after a quick search on the web, most of the articles on this topic highlight technical knowledge, the need for good tools, knowledge on how to use those tools and other related technical skills. Although these skills are very important, they do not make great developers.

When I interview new developers I often ask if they know a particular technology or tool that is not listed in their resume. If they say that they know I probe a little further and may even ask why it is not on the resume, depending on the circumstances. The good ones, those who often get the job, say that whilst they don't have experience working with this specific technology, they can learn quickly and become productive in a reasonable period of time. If I can find evidenced of it in the resume and I confirm during reference checks, that will be the developer that gets the job.

In conclusion, I don't think that there is a definitive list for what makes good software developers as it varies depending on the circumstances. In broad terms, I find that attitude, openness to discussion and business knowledge are some of the skills that will give developers the edge they need to succeed in their careers.

The Decline and Fall of Traditional IT

IT (Information Technology) as we know it came to a fork in the road several years ago. The traditional IT department used to deliver technology with a service component. Now we provide service with a technology component.

What does this really mean? Let me provide several examples of the transition from information technology to information services:

• The IT department used to deliver technology projects. Now the department delivers project management services. These services include IT functionality, but not exclusively.

• IT departments used to build a complex infrastructure of networks and servers and workstations. Now the department delivers an enterprise architecture articulating how everything fits together.

• Staff members in IT were the back office geeks. Now the department trumpets service-orientation with world-class help desks and sophisticated escalation processes.

• Security was a deny first, enable later process. Now the department defines security by corporate policies. These policies follow national and regional privacy laws, enable multi-layered authentication for a variety of roles, and facilitate freedom of information legislation.

• IT departments used to hand-craft software to meet every nuance of an organization's processes. Now the department staff are master negotiators working with a sea of vendors to deliver information services written by a vast array of industry subject matter experts who have never set foot inside the organization.

These are the facts crafting our new reality. The implications for the future of IT are undeniable. The decline and fall of traditional IT is complete. Organization do not need, nor do they want, a traditional information technology department. What they crave is a world-class information service organization.

~

Digital Strategy & Execution - The "What Sandwich"

I try to use analogies that help stakeholders get their heads around some of the abstract concepts floating around in a marketing environment. Strategy and its proper relationship to Execution is one of them.

This is not a post on the elusive definition of strategy. Nor an attempt to define the difference between Strategy (with a big "S") vs. strategy (with a small "s") or Strategery or any of the other silliness that surrounds this term.

I like to think of the relationship between Strategy and Execution as a "What Sandwich" or, more specifically, a sandwich comprised of "What" needs to be built, that lives between 2 slices of "How" objectives will be achieved and "How" the features and functions will be executed.. The sandwich is made like this:

I'll leave the deeper question of "Why" for another time or other minds.