Agile Charlhttp://agilecharl.com
Making your day more agile one step at a timeSat, 29 Jul 2017 21:49:32 +0000en-UShourly1https://wordpress.org/?v=4.8.169499479Getting Behind the Project Progresshttp://agilecharl.com/manage-project-progress/
http://agilecharl.com/manage-project-progress/#respondSat, 22 Jul 2017 11:09:26 +0000http://agilecharl.com/?p=652 Understand the project progress Good project progress is not easy to achieve. The project manager needs to keep an eye on it at all times, in order to make sure it makes steady progress. Every person in the team and each activity work together as a unit. You can see the full picture by understanding each component. […]

Good project progress is not easy to achieve. The project manager needs to keep an eye on it at all times, in order to make sure it makes steady progress. Every person in the team and each activity work together as a unit. You can see the full picture by understanding each component.

The project will become more clear, therefore increase the chance to complete on time. When you understand each area well, no doubt the complete project will be easier to understand.

Is a project a person or not?

You can further make the job easier, by thinking of the project as a person. It will behave in ways, which will leave you puzzled. The results are often difficult to understand, as a result of how each person acts. Team work is dynamic for this reason, it is not easy to keep track of all work at all times.

We can make difficult topics easier, before jumping into managing a complex set of work. The task of tracking work can be made easier, for instance by thinking of the project as a person. This approach allows you to monitor progress at a higher level, therefore you can spend less time on the details.

Steady project progress is key

Steady rate of work

You can free yourself from managing work, which is less important by thinking at a higher level. A steady rate of work is then possible, with this in mind. The freedom of having less work gives you the option of focussing on the more important task of keeping the work in sync. Keeping the work in sync will result in a steady rate of work.

You need to get into a habit of stepping back when you are overwhelmed by strange behavior. The next step is to ask the question, “Why is the person (project) behaving this way?”.

]]>http://agilecharl.com/manage-project-progress/feed/0652Agile Team Size, Does It Matter?http://agilecharl.com/agile-team-size/
http://agilecharl.com/agile-team-size/#respondSun, 31 Jan 2016 15:49:51 +0000http://agilecharl.com/?p=722Looking at the agile team size of others Comparing your Agile team size to others is not a good way to start using Agile. People always compare their current situation to others. Why do we do this … the answers are many. Lack of confidence, trying to validate, seek growth opportunities and many others. It should be […]

Comparing your Agile team size to others is not a good way to start using Agile. People always compare their current situation to others. Why do we do this … the answers are many. Lack of confidence, trying to validate, seek growth opportunities and many others.

It should be clear that learning from each other is good and well. The topic of this post is not to suggest we do not share ideas. In facts Agile can only grow when sharing our ideas.

Agile Team Size is Relative

One size does not fit all

The question is often asked when implementing Agile. Is our team the right size for Agile? Simply put there is no way to measure the right Agile team size. If taken in context it also does not make sense to try and determine team size.

There are some guidelines to use in order to create a starting point. As always it is key not to follow “Agile rules”. Typically a team is good with 4 to 7 members in my experience. But it does not mean a team of 2 or 10 does not work.

The same idea applies to company size. You could be a company consisting of two people. On the other hand you could be a global company. The size of your team or company is not a measure if Agile will work for you. A shining example of a large company using Agile to grow is Salesforce.

Accepting you Agile Team Size

Team size should not be the main focus when starting with Agile. Use guidelines to start, for instance a team of 4 people. The focus should then be on how the team is adopting the process.

The more important question is how is my team doing? Are people feeling confident? Is the Velocity healthy? Communication, is my team talking to each other?

It is once you know your team and see a problem when you ask questions about team size.

]]>http://agilecharl.com/agile-team-size/feed/0722Walking Towards Agile with Easehttp://agilecharl.com/walking-towards-agile/
http://agilecharl.com/walking-towards-agile/#commentsTue, 05 Jan 2016 23:42:27 +0000http://agilecharl.com/?p=726Why Walking towards Agile and Not Running Being Agile is mostly about being responsible. Agile works when people do their own work. It is important to know what is expected from us. We tend to look at our job description or listen to others to understand this. Using these sources is like running towards Agile. […]

Being Agile is mostly about being responsible. Agile works when people do their own work. It is important to know what is expected from us. We tend to look at our job description or listen to others to understand this. Using these sources is like running towards Agile. Walking towards agile is taking the time to know your work. It is important to know how you fit into your work.

Walking Towards Agile

Humbleness and Love

My recent post Lasting Change for Your Life explain humbleness and love at work. Maturity is needed to make this part of our daily life. The key to walking towards Agile is to be mature. We should avoid getting into the “us-against-them” syndrome. Also the “i-am-just-doing-my-job” is not being Agile.

Taking Stock

It is important to understand the mission statement of the company. Many sources within a company can assist you with this. Some companies are open about their goals and it would be easy to determine the general direction. Your direct manager could be another source, human resources another or reading company documentation.

The next step in walking towards Agile is to understand how your group, department or team fits into the company goals. This is also a good time to discuss your approach with your manager or team lead. Your manager will appreciate your pro-active approach and also give you the correct understanding on the strategy for your group, department or team.

What is expected from me?

You should be walking towards Agile at a slighter faster pace from this point. Take your job description we mentioned earlier. Read it carefully and try to understand the main purpose for your position within your team and finally the company. It would be great to distill it into one or two sentences. Look for areas which are not clear or which are not in line with your current understanding.

Conclusion

It may happen than your view of your position and what was asked for originally does not match. This should never be a point where you get nervous palpitations. This should make you be thankful since you saved a lot of time and energy working in the wrong direction. It may feel that you are not walking towards Agile, but we will discuss in a later post why you made the first step already.

]]>http://agilecharl.com/walking-towards-agile/feed/3726Lasting Change for Your Lifehttp://agilecharl.com/lasting_change/
http://agilecharl.com/lasting_change/#respondWed, 30 Dec 2015 10:02:58 +0000http://agilecharl.com/?p=731Why do we need lasting change? Lasting change is not always simple to achieve. Most of us try to avoid it and at times even fight it. It is still the only way we can grow. It also fulfills our needs in life. My father used to say military service is something he would not do […]

Lasting change is not always simple to achieve. Most of us try to avoid it and at times even fight it. It is still the only way we can grow. It also fulfills our needs in life. My father used to say military service is something he would not do again but was glad he went through it. Difficult change is something we do not always welcome. Yet it is something we often cherish once the results are visible in our lives.

Great change management tools are humbleness and love. I would ask you to hold off on rolling your eyes until the end of the article. These two words have been butchered and pushed into the far corners of avoidance. It’s however, these exact words we need to achieve lasting change.

False humbleness is also not the target. It is this kind of “humbleness” which is actually pride. People see through this fairly quickly and reject it. Perhaps more of this thought at a later time. It is also difficult to have false humbleness and lasting change at he same time.

Love is far more than just romance.

Lasting change through love

Our Valentine’s Day only word is love. We have lost what it means. The ancient greeks thought of love in many ways. We currently “love” chocolate and “love” our best half in life. Surely we cannot have the same feeling for both.

This following definition guides me in everyday life and I have to admit it is hard to apply at times.

Love is patient, love is kind. It does not envy, it does not boast, it is not proud.It does not dishonor others, it is not self-seeking, it is not easily angered, it keeps no record of wrongs.Love does not delight in evil but rejoices with the truth.It always protects, always trusts, always hopes, always perseveres.

Conclusion

Being humble puts people in perspective. It allows us to put others first and ourselves last. It sounds like the wrong way to look at things, but no man is an island. We need each other to succeed.

And we have love which forgives, trusts and hopes. People can be tough on each other. We have daily events which give the chance for fear to take root. The secret sauce to lasting change is to love back even when we do not feel like it.

Being humble and loving others opens the doors to a huge amount of ways to grow.

]]>http://agilecharl.com/lasting_change/feed/0731Health of a project team should be plannedhttp://agilecharl.com/health-of-a-project-team/
http://agilecharl.com/health-of-a-project-team/#respondSun, 28 Dec 2014 13:33:16 +0000http://agilecharl.com/?p=669New year resolutions are often made to improve health. These resolutions are often broken early in the new year. This is most true when it comes to health. Perhaps a new way would give better results. It starts with thinking about money, time, and health at the same time. Which of these is more important? The […]

These resolutions are often broken early in the new year. This is most true when it comes to health. Perhaps a new way would give better results. It starts with thinking about money, time, and health at the same time. Which of these is more important?

The love of money is the root of all evil. This lesson is often misquoted. Money is not the root of all evil but the love of it is. What does the love of money mean? It is to want money more than having money for a specific reason. We need money and it is a good thing. It should however not be the focus but just a tool. A project should consider money, some projects might even generate funds. However making money the focus at all cost is never a good long term strategy. Personal health of team members should never suffer to save or increase money.

Personal health over finance sounds moral. But it also makes financial sense. Healthy team members think better, work better, and are more motivated. It is not often that managers think of this touchy topic. It could perhaps be the easiest part of a project to manage. At first it may sound that a lot of time is needed for this. In fact it saves time once the team is in the habit of managing their health.

There is a time and a place for everything. Great leaders focus on getting the timing right. Health of the team improves greatly when time is not a problem. Time well spent will in most cases increase the useful time. It may seam like two steps back but long term it will be more than just two steps forward. A well run project is very often the result of good time management.

Tomorrow brings its own worries. It is easy for us to stress over time and money in a project. We must keep our focus on our health and not the problems of tomorrow. Planning and stressing are often confused with each other. The solution is faith. Believing each day will have its own problems. Also believing that you will have enough ability to manage the problems of a specific day. Keep this in mind and have the right focus. This will result in planning and not stressing.

What is it to gain the whole world but to lose your soul? Mental health has fortunately become a serious topic. We need to be comfortable with our decisions and sleep well at night. Pushing a team for performance is often needed. But pushing people at all cost does not help everybody. A successful project should also result in a healthy team.

]]>http://agilecharl.com/health-of-a-project-team/feed/0669Quality must be the first thought with a new producthttp://agilecharl.com/quality-must-be-the-first-thought/
http://agilecharl.com/quality-must-be-the-first-thought/#respondMon, 22 Dec 2014 16:16:41 +0000http://agilecharl.com/?p=650Creating a quality product has never been easier. Agile has become more mature and tools more creative. This combination has shortened the release cycles. We need to adjust to the quick change, in order to stay competitive. It is not an option to be just good enough. Being more efficient will be more important then […]

Agile has become more mature and tools more creative. This combination has shortened the release cycles. We need to adjust to the quick change, in order to stay competitive. It is not an option to be just good enough. Being more efficient will be more important then ever next year. This means we need to improve in multiple areas at once. Teams will rely less on experts. Working as a whole will be the success factor.

It seems like we have a new product every day. This is great for the clients, but it puts more strain on the team. A new feature can often also affect an existing one. Another problem we face is that the new feature does not have the quality as intended. It is often more important to wait than to be the first to release. Waiting for the right time to release or implement is the key to success.

Quality could at times be difficult to drive. Thinking about quality only during implementation is too late. A good product team thinks about this from the start of product design. A method to ensure quality is constant testing. Testing needs to be relevant and timely.

It is a challenge to test a fast growing product. The product becomes more complex quickly and too big to test. Features are also connected and each scenario needs to be tested. The best way to test large systems and ensure quality is to automate the tests. People who test with quality are rare. People who can write automated tests are even more rare.

Project stress often stops us to find the time needed to write tests. Adding tests during project can slow the project down. Slow projects can also affect quality. People will try and find the quickest way to finish. This is especially true when a project is already in delay. Tests are then seen as waste and not done.

Tests are more than checking for quality alone. It could be used to plan a project. Tests can be used for team members to discuss the feature early. This could save time, since wrong assumptions are tested quickly. The team then has a higher chance to deliver quality. In some cases the product team will change a feature early due to a test result.

Quality does not have to be difficult. Design tests from the beginning to be a benefit to the project. You also need to get the right QA and use the correct tools. Quality is then easier to be achieved.

]]>http://agilecharl.com/quality-must-be-the-first-thought/feed/0650Product Management has become a team efforthttp://agilecharl.com/product-management-become-team-effort/
http://agilecharl.com/product-management-become-team-effort/#respondMon, 15 Dec 2014 09:06:00 +0000http://agilecharl.com/?p=570Product management is done by the whole team. Product management is the key of a project. New products are created each day. At times it seems to happen too quickly. Quick product delivery is seen as normal. Quality cannot decrease with the speed. Products need to be easy and fun to use. The demands are high […]

Product management is done by the whole team.

Product management is the key of a project. New products are created each day. At times it seems to happen too quickly. Quick product delivery is seen as normal. Quality cannot decrease with the speed. Products need to be easy and fun to use. The demands are high and not easy to please. A fresh way is needed to achieve all of these.

Operations and projects have grown very close. Good product management keeps this in mind. Project change the way operations work. Operations affect how a project is done. A scrum master needs to keep both in mind. The product manager relies on the scrum master. A whole is greater than the simple sum of its parts.

Team members need to manage their own work. Project managers are also known as scrum masters. Analysts are now product managers. The new roles need a new way of thinking. Goals are still set, but the way of work is not. Product management is a team effort.

A project manager usually directs people closely. People were pushed to meet deadlines. This Waterfall approach did not work well. Project managers were only looking at targets. The targets were often outdated before the project finished. Keeping track of progress is still important. Progress is now used to see, how well a team does. The scrum master looks for areas to improve. The areas are then reviewed with the team. The team is then guided to improve work. A scrum master coaches the team. This is a form of product management.

Good product management is dynamic. The same is expected from the scrum master. Both will have a strong character. Work often overlaps in a good agile team. People work closely in agile teams. Conflict is expected in such teams. Conflict needs to be resolved quickly. Great products are created by great teams. Good conflict is needed to make great teams.

Our next post will cover product management done by the rest of the team.

]]>http://agilecharl.com/product-management-become-team-effort/feed/0570The Power of Scrum for Your Teamhttp://agilecharl.com/scrum-power-gives-team-deserve/
http://agilecharl.com/scrum-power-gives-team-deserve/#commentsMon, 08 Dec 2014 09:24:31 +0000http://agilecharl.com/?p=525The power of Scrum is best seen in teams which understand the idea Using Scrum in an Agile environment correctly is more than pushing people around. In fact it is rather the opposite and it is more about working with people in a way which respects them. Projects has for far too long been seen, as […]

Using Scrum in an Agile environment correctly is more than pushing people around. In fact it is rather the opposite and it is more about working with people in a way which respects them. Projects has for far too long been seen, as a way to make people’s life difficult.

The scrum within a rugby team, is one of the key points which makes a team. It consists of 8 players, who all push together with the goal of winning the ball. Each position in the scrum has a role to play and it is only the sum total of all players which makes the difference. Each player has to be the best in his position. The true power comes when each player understands what is required from him and works with the rest of the scrum. The coach gives the game plan and as a whole the team pushes together.

The front part of the scrum consists of the physically stronger players. The front players are the foundation, with the rest of the scrum build around it. Everyone relies on them to stand strong and resist the pressure from the other team. In software development we have similar team members, on whom everyone relies on to support the rest of the team. They could be product managers, senior developers or system architects.

The next part of the scrum are the locks and flankers. The locks take the ball from the front players and pass it to the back. In development teams we have the less experienced developers, taking the ball (software) from the more experienced members mentioned above. The flankers are the players on the side of the scrum. They are called loose players and are expected to be creative. We have team members in development, who manage the creative tasks. UX, designers and front-end developers come to mind.

The eightman at the back of the scrum, binds to the second row. The purpose of this player is to push the scrum into a direction from behind. He also holds the ball between his feet at times, to find the right time to release it. The product manager comes to mind.

So where does the scrum master fit into the scrum? There is a small, yet very important player called the scrum half. The scrum master in many ways needs to “play” like this player. His strength is not in pushing players around. His real value is his nimbleness to find the right moment to throw the ball into the scrum. He also has to find the right time to take the ball from the scrum and pass it to the other players on the team (company). The scrum master needs to pick the right time for the software to be released to business. He needs to correctly time,when the software is released from the team.

The eight man and scrum master has to communicate well. The same is for the product manager and scrum master.

All of these players scrumming together, creates a symphony of a winning team.

]]>http://agilecharl.com/scrum-power-gives-team-deserve/feed/8525Contracting as a way of life, not just a choicehttp://agilecharl.com/contracting-way-of-life/
http://agilecharl.com/contracting-way-of-life/#commentsMon, 01 Dec 2014 16:31:20 +0000http://agilecharl.com/?p=443Contracting can be viewed as both positive and negative. Starting out as a contractor can be very challenging. Your mindset changes and you feel the pressure of the small margin of error. The safety of working for a company is gone and it depends more on you than ever. How you view this will determine the […]

Starting out as a contractor can be very challenging. Your mindset changes and you feel the pressure of the small margin of error. The safety of working for a company is gone and it depends more on you than ever. How you view this will determine the success of being an independent contractor. Changing my point of view was the first thing I had to do.

Contracting is not a new topic to me. The difference this time around is that I do not have a long term contract. My previous contract was for a single company and it lasted for more than 4 years. This means that I was basically a full time employee, working at a contractor rate. Making the decision to become a contractor again, took a lot of careful thinking.

Every person gets used to a certain standard of living. It was a natural for me to start with the question of much do I need to live? Finances is not always a comfortable topic for every person. It is however the main motivator for the work we do. Some people will explain that money is not important. I would kindly have to disagree. Working is fun for me at times and does motivate me most of the time. The main motivator however, is to provide for my family.

Some people work for the sole purpose of increasing their wealth. It has always been my view that the love of money is the root of all evil. It is obviously nice to have money when you need it, but it should however not be our main motivator in life.

Looking for the balance between earning enough money and time has been a key consideration for me. Time can be earned in many ways. I have found that the easiest way is to do the right things and not to do the things right.

Contracting provides me with the opportunity now to strike the balance. This initial thought to determine what is more valuable was a key factor to choose contracting.

]]>http://agilecharl.com/contracting-way-of-life/feed/1443Virtual project teams vs locally managed teamshttp://agilecharl.com/virtual-project-teams-vs-local/
http://agilecharl.com/virtual-project-teams-vs-local/#respondMon, 24 Nov 2014 07:14:48 +0000http://agilecharl.com/?p=488Having your team members next to you is easier, then reaching them in the virtual abyss. It sounds simple enough to use the same approach for both a virtual and a local team. Reality is completely different. One quickly sees the difference when you do not meet people face to face. You have to adjust just about all […]

]]>Having your team members next to you is easier, then reaching them in the virtual abyss.

Strategy orientated team

It sounds simple enough to use the same approach for both a virtual and a local team. Reality is completely different. One quickly sees the difference when you do not meet people face to face. You have to adjust just about all of your thinking.

People working in virtual teams, also often have a very different view of how to work. You get the extreme cases of people who need no management to people who need specific instructions. Local teams tend to have people who are more in the middle of these extremes.

The initial adjustment I had to make was to keep in mind that virtual team members work different hours from each other. Your day has to be planned, to make sure that you can see all topics per person very quickly. The reason for that is that you may have a small amount of time to speak. Looking for the topics to be discussed is not always an option. In addition, it may take some time to speak to the person again. You may need the information or get the task done before you speak at a later stage.

People in remote teams chose the working style for a number of reasons. It is important for you to be aware of each person’s reasons. Examples of such reasons are flexability in hours or in some cases the freedom to work on multiple projects at the same time. Understanding each person in your team on this level will allow you to understand how each person can contribute or pose a challenge for each project.

It may be that I have a strong personal opinion, but virtual project teams work best with agile methodologies. The mind set of agile is aligned with the way virtual teams work.