SOGETI UK BLOG

Image 1“We can’t share anything on public internet before completing security audit.”

“All changes made to an environment must be approved by managers.”

“Applications can be updated only during predefined times.”

Familiar statements … right? You might be wondering why I mentioned testing explicitly at the title. In fact, testing is implicitly included in all steps. Security audit is also just one kind of testing. Tester(s) are quite often the ones who get the blame if applications can’t go live due to the detection of bugs. So it’s preventing “everything nice”.

Luckily, there are some companies that think differently. In those companies it’s enough that the code is in version control and automated tests pass to install new version to production. Without any human intervention.  Also improvements or fixes for the application can be made quicker. It’s enough to notice something that needs to be changed (improvement, error) in the application and tell that to product team. The feature can be fixed or implemented to production much faster than most people can expect.

So, the good part is that we clearly see quick fixes and new features. This can be also seen as a problem. So first thing to do is to trust each other. E.g. that developers do not make mindless implementations, and are able to fix things successfully. And also that business people can make decisions, without getting approvals from some steering groups or committees.

So, in a nutshell:

  1. Trust people and let them do things that they’re good at
  2. Trust that people are doing things the correct way and verifying that the results of their work, works.
  3. Help people by removing obstacles instead of creating those.
  4. Use time for doing things, not for building (manual) safety nets.

All this is part of DevOps, so why not to try that yourselves?

 

Juho Saarinen AUTHOR:
Juho Saarinen joined Capgemini Group, more specifically Capgemini Finland, at the end of 2007 as an analyst tester. He was moved to Sogeti Finland when it was established at 2010, and has advanced from Analyst to Manager responsible of testing tools, test automation and agile portfolio.

Posted in: Automation Testing, Developers, DevOps, Security, Testing and innovation      
Comments: 0
Tags: , , , , , , , ,

 

Image Credit: wpglee.comWhile being in the consulting business for 8 years, I have seen how businesses (clients) have managed to get what they wanted; and that too, much faster and at lower cost than expected! This might sound a bit strange when considering a regular IT project.

So, what’s the ‘silver bullet’ that has made it possible? The simple answer is – working together. This also means making things that are reasonable; and not just making things because these are in the Requirements (it’s a part of a contract that specifies the things that must be done). So, the right approach to achieve the desired results here, would be to adopt the ‘Agile’ methodology.

Although, Agile originated in 2001 from the Agile Manifesto, it still seems to be a new concept for many companies! People still try to do things ‘as we have always done’ with lots and lots of specifications/requirements. At times, even a separate project is initiated to create the Requirements. Finally, those Requirements go to some ‘implementer’ for conversion to the working system. And, when (note when, not if) there’s something that’s outdated in the Requirements, it still needs to be implemented! Not because it’s reasonable, but because it’s in the Requirements! This is completely meaningless!

Then, what is the solution? Though ‘working together’ is the best option, it doesn’t help if Requirements are monolithic. A good start could be converting these Requirements into smaller and more manageable user stories. Then, especially if a contract is bound to those original Requirements, some mapping would be needed. It can be just a whiteboard with post-it notes. If people are working from different locations, some (simple) management tools can be more effective. The most obvious and easily available one is Excel, however, investment in some other useful project management tools can make things easier, at least, towards the end. Using a new tool is always an investment, even if the tool is free or easily available to everybody already (as Excel).

Here are some tools that can really help add value to projects:

Great technology or a brilliant business idea alone can’t change the world. These need to be combined with the right mix of people and effective collaboration. If done well, there would be no limits to what a project can achieve.

To read the original post and add comments, please visit the SogetiLabs blog: What’s the Silver Bullet for Successful Project Management?

Related Posts:

  1. Is coaching the very new key success factor to make project management more efficient?
  2. Manage project or deliver?
  3. Agile series: The misconceptions
  4. Will project managers survive the agile trend?

Juho Saarinen AUTHOR:
Juho Saarinen joined Capgemini Group, more specifically Capgemini Finland, at the end of 2007 as an analyst tester. He was moved to Sogeti Finland when it was established at 2010, and has advanced from Analyst to Manager responsible of testing tools, test automation and agile portfolio.

Posted in: Behaviour Driven Development, Business Intelligence, Developers, Digital strategy, IT strategy, Microsoft, Opinion, project management, Technology Outlook      
Comments: 0
Tags: , , , , , , ,

 

dilemma-270x300There are times when the implementation team (comprising developers, testers, UI designers, etc.) is considered not good enough to complete a project or get things done on their own. There is a general tendency to include senior management to the list of “responsible people” for important projects, as it’s commonly believed that the management can solve all problems.

If senior managers are not seen or heard, everything is considered to be OK. A bit like “no feedback is good feedback.” However, when there is a problem, senior managers feel an urge to solve it, as they think it’s the most  reasonable thing to do.

Now, the problem with this resolution method is that it involves “more bureaucracy.” This, especially, poses problems when the team has found efficient ways to do things – such as applying agile methods with good tools suitable for work (tools that help manage the requirements to see what is not done). One should not forget that these tools cannot perform miracles! If the  team, for instance, does not estimate correctly, the tool can’t figure out the remaining work on its own.

People really need to ask themselves at such moments: “What should be our priority… to deliver this project, or just try to manage and report it?” I think, most teams ask this question but end up doing the latter one. Here, unfortunately, resistance is futile, because orders always come from the higher level!

So, here’s some food for thought for all of you. Applications (such as JIRA and Scrumworks) can be helpful in such cases, but first you need to ask whether you are reporting for the sake of it or is there a real need for reporting. Find out what actually needs to be known/done, rather than simply following what was done earlier.

Related Posts:

  1. Is coaching the very new key success factor to make project management more efficient?
  2. Why would a project leader need a coach when he already has a manager? What about having more “manager coach”?
  3. Will project managers survive the agile trend?
  4. From the « closed project » to the « social coding

To read the original post and add comments, please visit the SogetiLabs blog: Manage project or deliver?

 

 

Juho Saarinen AUTHOR:
Juho Saarinen joined Capgemini Group, more specifically Capgemini Finland, at the end of 2007 as an analyst tester. He was moved to Sogeti Finland when it was established at 2010, and has advanced from Analyst to Manager responsible of testing tools, test automation and agile portfolio.

Posted in: Managed Testing      
Comments: 0
Tags: , , , ,