By saying that Agile framework is top trending in project management techniques these days, is easy to find plenty of variety on tools that provide at least one ‘cool’ and ‘useful’ benefit that is also ‘so fast and easy’ to customize and fit just right in your project.

Free or licensed, there are quite amount of options, and yes, they are all configurable, colorful, useful, but yet not all practical, and far away from magical.

As I’ve mentioned in previous posts regarding Agile, nothing in Agile is a step by step recipe to pursuit success, neither a set of tools to become Agile for real, but suggested good practices. Anyhow tools are always a huge support for managers but, careful here, not quite for developers.

The main goal while learning about any Agile framework, their values, principles, nice practices and ceremonies, is to deeply assimilate the Ideology terms, so that all people in the team be able to truly identify the new responsibilities we’re committing while adopting this new framework. I don’t think we all know the impact of migrating from a SDLC methodology to an Agile Framework, and not all in the team are prepared for such change.

The easier and faster goal is to get in touch with the new tools, to understand how to use them, and to configure them, are the most excitement part of the migration. Tools commonly allows you to do pretty much anything, no matter if is not that useful, practical, or efficient, sometimes ends up being more painful for the team.

Analysts and managers are more used to use tools so, adoption of new tools is part of the day to day basis for them. Dev team members, on the other hand, might suffer a bit more while adopting these new practices of sizing realistically, then tracking tasks, and finally providing daily progress.

Furthermore, on both sides of the team, another stressful point is to accept that scope per sprint is now part of the Dev team core responsibilities, which are negotiable with the management side, yes they are, but the actual delivery scope must be defined per the team who’s actually building it, I mean, must be a Dev team decision.

I mentioned this because, while much people get amazed by the tools, they may be distracted, skipping, or avoiding the proper discussion of something important, and when real work life begins, these kind of things that were not mentioned on time to be considered, agreed, and accepted, triggers some uncomforted discussions, ending with the convenient distorting, or partial adoption of the Agile best practices.

Be extremely care on this, getting new Agile tools but keeping the exact same practices, perhaps from a lineal or SDLC methodology, don’t make your team an Agile team at all, and believe me, doing that is just more frustrating for the team that remain a waterfall team.

Being Agile is not about tools ever, yes, Agile has a ton of tools to ease the work, to actually implement the suggested practices by using trend tech to be faster, and easier, and global, but Agile can be done, and must be done even without the tools. I mean, yes you can have a digital app, share screen with such colorful board which contains all the team member photos to filter tasks, you can add a link conference, play Agile Poker in the digital tool used to estimate, but focus, best practices is the most important topic, not the fancy tool. Please don’t you dare to not have a daily meeting once, because of lack of conference room availability. Got my point, right?

As I said, best practices must remain even when tech fails or is limited. Estimations should be seriously taken, scope should be negotiable but realistic, team concerns and decisions should be always considered, management should be flexible, stakeholders should be committed and available, communication should be strong, feedback should be timely, improvement should be constant.

Per example, when we talk about “working software over comprehensive documentation” principle, we all commonly think: when Agile, you don’t need to document anything anymore, and that is so not true. Yes, you don’t need a bunch of huge analysis documents that provides an entire solution to be developed during the following two years, that nobody reads, nor understands less follows. But you do need to document your code properly so that anyone else can reuse. Also, even when you don’t have to create these hated solution design documents, or the endless Business Requirements Cases, or the fearsome project timelines, you do have to establish a high level strategy to follow up the implementations the team is expected to do, linking somehow the business goals to meet with the stories to be built, roadmap is called on Agile, and yes, is pretty much a document too (much more flexible I’d expect, than a static timeline).

Don’t worry, tools makes Agile documentation and all Agile Practices much easier to achieve, but remember again, tools don’t do the work for you. Tools are as Agile, as the team force tools to be, by implementing the Agile good practices on them.

Similar posts: Co located teams and Globalteams , As Agile s the Waterfall budget allows it