by Awesome Author | Oct 3, 2020 | Computers & Software
Managing successful IT projects with Agile.
While the application of project management is not new, the advent of project management ‘approaches’ or philosophies has led to significant improvements in the quality of projects delivered and the overall project management process itself. Gone are the days where an excel spreadsheet, work in progress (WIP) meetings and reliance on Microsoft Office programs were sufficient IT project management tools. Now we are spoilt for choice with an increasing number of methodologies available to keep even the most complex of projects on track and within budget, while allowing for improvements to be made that may sit outside the original scope.
But when it comes to choosing the right project management methodology for your business there are many factors that come into play – such as the type of work you produce and the industry you (or your customer) are in. Today, we want to focus on one such methodology that has been critical in the successful management of technology projects: Agile.
Meet Agile.
An IT project is rarely touched by just one person. From the project manager overseeing the workflow through to the back-end developer, a collaborative approach is key – and with collaboration comes open communication and sharing of ideas. A fixed, traditional project management approach relies on the initial scope to be delivered and the budget and timeline will rest on this. But what if an unexpected idea pops up that may result in a more successful product – yet the timeline or budget doesn’t allow for it? Scope creep sets in or (potentially worse) the idea doesn’t eventuate at all.
In our view, the most successful projects are those that are responsive and allow for change along the way – and therein lies the key difference between Agile methodology and following more conventional methods of IT project management.
A fresh approach to project management.
To further explain Agile we need to compare it to a traditional project management methodology – let’s take Waterfall, as an example.
Waterfall is a linear project management model that relies on one phase to be completed in sequence before another can begin. While timelines can be relied on and there (should be!) no scary surprises with cost, there is rigidity in this approach. Changes cannot be easily implemented and long-term projects may struggle to remain on track.
Agile on the other hand offers greater flexibility, making it well suited to ongoing projects of a complex nature. As explained by Agile Alliance, Agile is an overarching term for “a set of frameworks and practices based on the values and principles expressed in the Manifesto for Agile Software Development and the 12 Principles behind it”. It is in essence a more realistic approach to how projects with many components should be managed.
The four values that underpin Agile are:
- Individuals and interactions over processes and tools
- Working product over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
It’s important to note that the Agile methodology doesn’t suggest that all documentation, contracts, or plans should be disregarded or thrown out with the trash; rather that the focus of a project should be on collaboration, flexibility and responsiveness – and when these values have adhered to businesses can expect boosted productivity and higher-quality output.
What’s in a framework?
The above values and their associated principles form the basis of the Agile methodology, but to be successfully implemented a framework or system needs to be implemented. The three most widely used options are:
- Scrum (Used by Netflix, Adobe, Amazon, and Apple)
- Scrum works well for large-scale, complex projects that rely on multiple tasks to be actioned as quickly and efficiently as possible. Projects are divided into manageable tasks, or ‘sprints’, which are monitored in daily Scrums (meetings). The regularity of the Scrums allows for continuous feedback and collaboration, and as each team member has clearly defined sprints Scrum promotes a culture of transparency. On the flipside, disadvantages to be aware of include an optimum team size to make it work (minimum three, maximum nine/ten) and the need for one or more team members to have the right experience to provide meaningful feedback.
- Kanban (Used by Zara, Spotify, Pixar, and Toyota)
- Team members in a Kanban Agile environment are across a project’s workflow in real-time via a Kanban board. The board – which may be as literal as a whiteboard or a software program – forms the basis of the Kanban framework, with a project’s associated work items and their status able to be visualized at a glance. Considered an ideal framework for businesses new to Agile, it’s important to note that Kanban does run the risk of overcomplicating a project – so team members may still need a WIP to minimize confusion.
- Extreme Programming (XP) (Used by IBM, Ford Motor)
- Popular among software developers, XP enables teams to produce high-quality outputs while allowing for customer changes to be implemented throughout the process. This is enabled due to the level of testing undertaken, frequency of releases and an open channel of communication between customer and developer. While many programmers may find the idea of direct customer contact unnerving, the XP methodology is heavily reliant on mutual respect for it to work – and daily scheduled ‘stand up’ meetings should reduce the occurrence of ad hoc requests.
So, should I choose Agile?
No two businesses or cultures are the same – so knowing if Agile is right for your organization can only be determined by you and your stakeholders. But to guide you with your decision-making, several factors to be taken into consideration include:
- What is the organizational structure like; does it allow individuals to work in smaller teams without reliance on those in leadership positions?
- Do the types of IT projects you produce allow for collaboration both internally and externally?
- Is the culture of your workplace or team flexible in nature and are individuals open to change?
- Will Agile and your chosen framework allow people to deliver their best possible work?
Final thoughts
It’s important to have a healthy project pipeline – and we know that success is built on a collaborative approach. A team must be keen on their framework of choice and the rest of the members must be clear about their outcomes and daily stand-ups to keep the entire team on the same page and regular sprint demos that enable customers to provide instant feedback. The Agile methodology may not be right for others – so it’s important that businesses considering this approach undertake proper due diligence before taking the leap.
The original article by Bilal was published at Makeen.io
Featured Image Credits: Pixabay
by Awesome Author | Jan 27, 2020 | Management & Leadership
By Lucasz Wedel – Introduction: Every now and then I am sharing my thoughts on the management, growth of the company or just a clear description of the role that I held in the past. In this one, I am addressing a problem that I believe is currently slowly getting more and more visible.
The problems I am answering are the questions I received during some discussions about how to manage a remote team.
How to manage remote teams?
I was working remotely for a few years – both as a developer as well as a manager. What I noticed is that a small change in your management style can boost the productivity of remote teams, drastically.
Problem
I – a person that can introduce change in a company – want to make sure that I have the best team working on my products, no matter the location.
In short, you want to introduce a remote work option.
Solution
Hiring a remote worker is the “simpler” part. Making sure that they are motivated, feels part of the team AND are doing all they can is something entirely different.
Let us simplify the previously stated problem into something we can focus on.
Problem 1.
I do not want these remote workers to be mercenaries – I want them to be part of the team.
The majority of meetings are just time-wasters, saying that – let us focus on the part that is in the minority.
1. The team must feel part of the company – in my previous companies we did this with a bi-weekly/monthly catch-up. At this meeting, we are discussing the ongoing activities, goals, and plans we want to fulfill. We are sharing information that is limited only to the company so that we are showing our trust.
2. Project meetings – kick off, grooming, standups, retrospectives, demos – the team works as one and have the defined meeting. The team is working as a single organism, and with every iteration, it is getting better and closer.
3. 1on1s – a manager that oversights the team is crucial. They must have an excellent connection to the team, be the one they are approaching when there is an issue or problem.
There must also be a workaround – an escalation path that is known to everyone in the team. An unofficial mediator role – line manager, senior person or just a better communicator – should be approaching the team to chat with them and feel if some changes are needed.
4. Company events – seeing the whole company at a party is something worth practicing. Having a good laugh or just catching up and drinking a few beers creates stronger bonds and simplify the communication within the team.
5. Offtopic channel – where people can be sharing videos of cats or chat about a movie/game they recently finished. Something that allows them to blow off the steam and allow the brain to rest for a few minutes.
A remote management team is a self-healing organism, hence the 1on1 – where the single team member can show his opinion – and project meeting – where the team as a whole is providing feedback. A good manager based on these two inputs is capable of not only making sure the team feels part of the organization, but also motivate them and provide them with a place to grow.
Problem 2 & 3.
I do not know how to manage them, how can I know if they are working all the time they said they do?
How can I know if they are not working for my competitors?
You can’t, entirely.
The tracking software on the team devices shows a lack of trust.
VPNs are standard across multiple industries, but they are not allowing you full visibility.
What you have is a manager that sees how the team is working and people that are motivating themselves. Daily updates are providing the team with information, about who is working on what and how work is progressing. If there is an issue, delay or someone is just not doing what they should – the team knows, and the management team must act.
The manager is not the only input for information – demos, ticketing system, code repository, knowledge bases they are adding their parts are the places where you see the changes they are introducing and based on that you can make your opinion.
Image Credits
Problem 4.
How can I find a person that can work remotely?
Finding people that know how to work remotely is a hard one. Let me simplify this for this article’s sake.
Fast introduction to the terminology and context I am using.
JUNIOR:
- A person with at least one (1) year of experience, not able to be a single developer on the project.
- A person that requires support and mentoring by Senior/Architect developer.
- A person that is dependant on seniors/architects to organize training and growth for him/her.
- A person that requires a maximum introduction period when joining a company – average three (3) months.
REGULAR:
- A person with more than three (3) years of experience, capable of handling a project alone – but with some oversight from the Senior/Architect
- A person that is eager to participate in training and wants to grow technically.
- A person that requires an introduction period when joining a company – average a month.
SENIOR:
- A person with more than four (4) years of experience in at least three (3) companies, capable of handling a project alone – without oversight
- A person that organizes the training and growth within the company for himself/herself.
- A person that requires minimal to none introduction period when joining the company to be able to handle the technical aspects of the problems.
For remote work do not hire Juniors.
I know few that can perform as well as a remote worker. However, the majority of them do not know how to behave, how to work without face to face support.
For remote hire Regulars that had experience with remote working before.
For remote hire Seniors.
For the introduction period invite them to the offices that you have, let them see the company and feel the atmosphere. They should learn:
- Who is the person that I should speak if they want to discuss business/technical/hr?
- Where can I find any information about business/technical/hr?
- What is the architecture that we have?
- Who is on my team and how we communicate?
- What tools are we using daily?
Problem 5.
How should I share the knowledge and decisions?
I left the hard part for the end.
I had this problem with every company I worked for. You see, people from single office tend to share their ideas while having a coffee, a smoke, or solving some issue that was raised by the support. Documenting their decision is hard – as the fix usually takes just a few minutes to implement.
The problem starts later – a remote part of the team is not aware of the changes. They do not know the reasoning behind the decision, when it happened and what is the impact on their work.
The parallel problem tends to be the architectural vision that is not being shared and communicated. Due to similar communication paths as in the previous description, the remote team is not aware of the common goal that the company is chasing.
So what is the solution?
Think remote first, document, document, document.
A rule I am trying to enforce every time I can – no ticket, no work (I am a big JIRA fanboy). Tickets with details are always a good solution for figuring out why a change happened.
Sharing the company vision is equally essential, but this, unfortunately, is not doable with the tickets. Vision sharing requires diagrams, presentations and a discussion with all involved teams. You can not cut corners in matters like that. A vision must be understood and chased by the whole company.
Decisions?
I mentioned a bi-weekly or monthly meeting while discussing problem nr. 1. I believe that this management meeting is the primary source of information for the entire company.
- A person decided to quit – one of the topics.
- Someone is joining – one of the topics.
- We are trying the remote work approach – one of the topics.
- We released a new product – one of the topics.
- You should see now where I am going with this.
Summary
The most crucial part of it is always to thrive to be better.
The original article by Lukasz Wedel was originally published on LinkedIn
From the Author:
Lukasz Wedel is Program Manager at Cisco
In this article, I am focusing on the management of remote teams. I am listing issues I have seen in multiple companies, as well as on some tricks I am using to make sure that the team and company are working together towards a common goal. #startups, #corporations, #it, #management, #projectmanagement, #remote #remotemanagement
Featured Image Credits: Pixabay
