Discuss business intelligence, integration, compliance and a host of other SAP-related topics – implementation, best practices and resources to negotiate the world of SAP better!


June 10, 2014

Is Agile giving you personal fulfillment?

Years after the introduction of Agile development, many articles have been written about advantages of this software development methodology. Continuous delivery of working code, customer involvement and buy-in, quick response to a changing environment and self organizing teams are named among the many benifits. Agile is regarded as the optimal method to organize every IT organization. What strikes me is that only little has been written about the individual and Agile. When entering Agile and personal development in Google search, no results return. But isn't it that the members of the team are the once that have to strive for the agility of the method? And who will mentor them in doing this?


One might think that the Scrum master would have the role of mentoring any each member who needs personal growth, both technically as well as on a personal level. Cause doesn't the scrum master role have the same tasks as a team lead or project manager? Unfortunately this is not the case. By principal, the Scrum master is the facilitator of the group. The master is accountable for removing impediments for the team, so that the members can deliver the product goals and deliverables, not for people managing the once that need it. In practice,  a Scrum master acting as  a people manager might even result in conflicting responsibilities, unclear authority, and sub-optimal results. 


So if no people manager is available in a scrum team, is each member expected to be senior enough to self organize and motivate themselves? You can imagine that in a team, not all individuals work with the same enthousiasm and drive, which can cause frictions and different expectations. In a waterfall project a lead or a mentor could perform this steering or give personal attention. Who is there in a Scrum team?

Another shortcoming experienced in Scrum is the continuous sprinting. Personally, I have been sprinting for almost 4 years. Sprints in scrum can be seen as an interval running program; imagine 3 minutes of jogging at a quick 8 mph pace, followed by 1 minute slow walking, then 3 minutes at 8 mph again and 1 minute walking, and so on. But unlike interval running, where the run might end in an hour, scrum sprints have no ending. As if you are sprinting forever and ever. Often Scrum members complain about tiredness, because of continuously having to meet deadlines, without having an final goal or objective.

You might think that tiredness and lack of personal development could be solved by rotating roles and responsibilities. Just change your role every often from developer, to tester, to functional or even to scrum master. But are these roles interchangeable? Can a tester be a developer or scrum master. Mostly the roles and knowledge are locked and irreplaceable, due to the specific skill set needed.

So what do you think can be done to both reach the common goals of the team as well as cater to the personal (development) needs of each member?  




April 4, 2014

Development and support with Scrum; an integrated approach

The Scrum development methodology since a few years has been well integrated into the IT department of many organizations. It is considered to work well for numerous reasons

- Communication is vital to success in any project. Scrum promotes communication between project team members

- Scrum shows quick results. One or two iterations (sprints) are sufficient to show a working product to the client

- No time is wasted as all items are prioritised based on the business value

- The production team is a self-organised unit that works to reach the Sprint Goal on time. A mix of skill sets and skill levels are often ideal to promote a continuous work flow.

- Scrum promotes transparency: the client knows what is going to be delivered in the sprint, since he/she has prioritised the Product Backlog.

All success of the scrum team is focused on delivering a working product on time and meeting the quality standards defined. With the sharp timelines set in the sprintplanning, the support team often experiences a lack of knowledge handover by the development team. The support team is often left clueless of what code has been brought live at the end of the sprint cycle. Once the new code is in production it is difficult for the support team to perform issue analysis, as the team never received a proper knowledge handover.

In this article I would like to cover my experiences in Scrum development and the actions that were taken to mitigate the risks of poor handover of scrum products to the support team. A brief reminder of what Scrum methodology is; scrum is one of the Agile development methodologies that uses time boxed effort, known as Sprint cycles, to develop a working increment of a software. Sprint cycles (usually) last 3 weeks, in which requirement analysis, development, testing and documenting are all being performed. Which requirement are to be build in a Sprint are determined from a Product backlog (pool of user requirements) determined by the user community and moved into the Sprint backlog for planning. Each item on the Sprint backlog is called an Epic and can be narrowed down into separate pieces of coding called Stories. In order to determine the effort for bringing each Story live, Pokering takes place, determining how many Stories can be handled within a Sprint with the available resources. Every day team members gather in a Standup to discuss the work done yesterday, the planning for that day and possible impediments, in order to track the progress of each Story. After 3 weeks a review takes place of the work that was completed and not completed and a go/no go decision to Production is made. Finally in the Sprint retrospective all team members gather to discuss the past Sprint in a Retrospective, determining what went well and what the improvements are for the next Sprint.

The process is simple and logical; a scrum team has set its goal at the start of the sprint cycle, performs the tasks in de sprint, revises if needed and at the end of the cycle assesses the success of the sprint by its products. Unfortunately, nowhere in the process, handing over its knowledge to the maintenance team has been mentioned. It would look like the development team considers the delivery of the coding to production as the final stage of product, whereas it is actually the start of the functionality being used and support by the maintenance team begins. Considerable literature has been written on best practices for knowledge management in a Waterfall model. Knowledge transfer is often taken as a phase in the project delivery. Often at the end of the project execution project members would spend time discussing the newly implemented processes and functionalities to the maintenance team, or even involve them at an earlier stage (eg during requirement analysis or testing). Involvement and participation from the support team seems much easier to fit in a timeframe of a year or longer in case of waterfall, then in a sprint cycle that only lasts a few weeks.

Then how can we better prepare the maintenance team for the upcoming product releases, without interfering the development team in their tight delivery schedule? Introducing the Development-Support integrated Scrum model:

Development-Support integrated Scrum model.PNG

View image

The Development Support integrated Scum model adds a series of easy executable handover milestones in the existing Scrum model that tests the quality of product and delivered documentation as well as the readiness of the maintenance team to start supporting the functionality. The idea is to transition the product of a stage to the support team as soon as the development team finishes a certain stage in their sprint cycle.

The first stage for the development team in the sprint cycle is to determine the Sprint backlog; which epics and stories are committed to be delivered in the coming sprint. The list of epics are immediately communicated to the support team, so that they can prepare for what is coming. A Subject matter champion (SMC) in the support team will be assigned who will align with the developer for the remainder of the sprint execution. Requirement and solution documents that are available for the development team are also made available to the support team.

In the second stage handover the developer has finalized the solution of the epic. It can be on a minimum functional level or could be on a detailed technical level. In a short 15 to 30 min session, the solution is explained to the SMC, who at this point will have an understanding of why and how the solution will be build.

In a third stage handover the functionality is delivered by developer. It is ready for the SMC to perform some simple unit tests or integration tests on its own. This ensures that the SMC understands the functionality on a practical level and could even help the developer in finding bugs in the coding.

In a fourth stage handover the developer should have finished the necessary documentation of the functionality. What was not worked out in detail in the second stage handover should now be extensively described in functional and technical documentation or work instructions. It's the task of the SMC to check the quality and the completeness of the documentation.

In the fifth and final handover a stage is given to the SMC to show to the development and maintenance team what he/she has learned from all handovers in a Reverse Knowledge Transfer session. In short he/she will explain the rationale of the requirement and the solution. He/she should also be able to show the exact changes in the code in the system. To finalize the last handover a sign off takes place between development and maintenance team on the following objects

- Functional design documents

- Technical design documents

- Process model documents

- Business requirement documents

- Open issues list

- Performance testing documentation (if applicable)

The final handover is the official handover of the product to the maintenance team. The functionality is now ready to be supported in a live environment.

The Development- Support integrated Scrum model is way of working that is easy to implement for the developer, but intensive for the SMC; the developer at the end of every sprint stage (design, build, test, documentation) only needs to spend a short time to hand the product of that stage over the maintenance team. The SMC on the other hand has to spend a substantial amount of time through reading, analyzing and testing the coding. As the SMC will find this necessary to perform quality support of the functionality, this is not seen as an objection.

The Model is a good way to perform checks on every product of the development team. What is the quality of the coding, documentation and testing. And as the check is done immediately after the release of that product, corrections are easier to make. You need not wait until the end of the sprint to perform these checks. There would have been a greater resistance to perform corrections when the Agile team is already well underway in the next sprint.

The Integrated Scrum model is foremost an integration model. The maintenance team will feel more involved in the sprint cycle and be better prepared once the product is brought live. And that should be the ultimate goal of Scrum: to deliver a quality product that works in production. And if it doesn't work, then any issues should be resolved with little effort.


January 7, 2014

Bitcoins - should we care?

News has recently been dominated by the development of the value of Bitcoins. The price of the digital currency has risen from 250 USD from beginning November to a record high 1065 USD on December 8th only to drop half of its value in 24 hours again. Chinese government has prohibited national banks to trade in the currency as it indicated the Bitcoin has a high risk of being used by criminals and for money laundering. This has led to Chinese leading social network Baidu, which used Bitcoins as a trading currency, to stop excepting them. China's high powers evidently felt that the cryptocoin was getting too hot to ignore. So is Bitcoin here to stay or is it just another digital hype?

So for those who are not aware of the currency, what are bitcoins and what's it's use? Bitcoins were invented by a developer under pseudo-name Satoshi Nakamoto in 2009. Bitcoins are not tangible but only exist as a piece of code in a peer-to-peer payment network that is powered by its users with no central authority or middlemen. How are Bitcoins created? New bitcoins are generated by a decentralized process called "mining". This process involves individuals who are rewarded by the network for their services. Bitcoin miners are processing transactions and securing the network using specialized hardware and are collecting new bitcoins in exchange for their services. You can compare the function of this network of miners similar to a central bank, authorized to print and distribute the currency. How are Bitcoins used? From a user perspective, Bitcoin is nothing more than a mobile app or computer program that provides a personal Bitcoin wallet and allows a user to send and receive bitcoins with them. Behind the scenes, the Bitcoin network is sharing a public ledger called the "block chain". This ledger contains every transaction ever processed, allowing a user's computer to verify the validity of each transaction. As Bitcoin is a cryptocurrency; for each transaction, the bitcoin receiver shares a public address where the amount can be send to. With a private key, the receiver can then digitally sign the receipt. How do we know it's secure? The Bitcoin specification starts with the concept of a distributed timestamp server. A timestamp server works by taking a hash function of some data and widely publishing the hash. For Bitcoin, each timestamp includes the previous timestamp hash as input for its own hash. This dependency of one hash on another is what forms a chain, with each additional timestamp providing evidence that each of the previous timestamp hashes existed. To form a distributed timestamp server as a peer-to-peer network, Bitcoin uses a proof-of-work system often referred to as Bitcoin mining. Anybody can become a Bitcoin miner by running software with specialized hardware. Mining software captures transactions broadcast through the peer-to-peer network and performs appropriate tasks to process and confirm these transactions. For new transactions to be confirmed, they need to be included in a block along with a mathematical proof of work.

Bitcoins are created at a decreasing and predictable rate. The number of new bitcoins created each year is automatically halved over time until bitcoin issuance halts completely with a total of 21 million bitcoins in existence. When taking todays Bitcoin value (15 dec 2013) of 872USD, this means that the ultimate value in circulation is approximately 18 billion USD. One would consider this is as just a small amount compared to currencies such as Euros and USD's in circulation. But 2 important things should be considered. First the currency is only worth, when it's being used. When money is deposited on a savings bank and not spend, it's useless. Bitcoin payments are easy to make and can be used for small payments against minimum fees. If a bitcoin is being rotated from owner every day, the trading value per year can ultimately develop to 6 trillion USD, more than the Indian yearly GDP. Obviously, the circulation rate will not be once in 24 hours, but the advantages to do so are known. We will come back to that later. Second, a digital currency is a good replacement for national currencies that are non-tradeable or problem plagued. It's best example is the Chinese Renminbi which is only allowed to be exported or used in international transactions on a limit base, ultimately making it less advantageous for consumers to hold on to, unless they travel to China often and have the opportunity to spend it. For this reason Bitcoin is seen as a perfect substitution for Chinese consumers making payments outside of China. One third of all Bitcoin transactions are performed by Chinese. Also when a currency is plagued by volatility, the Bitcoin can be used to circumvent inflation, capital controls, and international sanctions. Bitcoins are used by some Argentinians as an alternative to the official currency, which is stymied by inflation and strict capital controls. In addition, some Iranians use bitcoins to evade currency sanctions.

Another major advantage of Bitcoin payments are that there are either no fees or extremely small fees. Users may include fees with transactions to receive priority processing, which results in faster confirmation of transactions by the network. Additionally, merchant processors exist to assist merchants in processing transactions, converting bitcoins to a currency of choice and depositing funds directly into merchants' bank accounts daily. As these services are based on Bitcoin, they can be offered for much lower fees (a payment of 0.0005 BTC for a 1,000 BTC transfer) than with PayPal or credit card networks (which usually request a 1 or 2% fee over the transaction amount)
Moreover, Bitcoin payments can be considered as secure, controllable and transparent - Bitcoin users are in full control of their transactions; The recipient holds a private key which is kept secret. Only the private key can decode information encrypted with the public key; therefore the keys' owner can distribute the public key openly without fear that anyone will be able to use it to gain access to the encrypted information. All information concerning the Bitcoin money supply itself is readily available on the block chain for anybody to verify and use in real-time. No individual or organization can control or manipulate the Bitcoin protocol because it is cryptographically secure. This allows the core of Bitcoin to be trusted for being completely neutral, transparent and predictable.

Even with the Chinese government banning the speculation of the currency by its banks or act as a middleperson for bitcoin payments, it seems like the Bitcoin use is unstoppable. Just todays issue of Business insider published that a Swedish company has sold 28 million USD worth of bitcoinminers, which has the processing capacity to mine around 4000 bitcoins per day. Techies show that bitcoinmining is lucrative and will stay lucrative until the last Bitcoin has been issued. And with its transaction processing advantage, more and more retailers are allowing customers to pay with the currency, it looks like the Bitcoin is here to stay. At least until a better, cheaper and more reliable currency is on the market.

February 14, 2013

Why consumers don't want a smart meter

The term smart meter usually refers to electric meters which keep detailed statistics on usage, but it can be used for gas or water meter as well performing the same job. Additionally, a lot of smart meters can also perform telemetering, in which they interface remotely with utility companies. Smart meters have been around for years. National governments have always been in favor of making them mandatory for every household, but among the consumers the controversy has never been this big.  This article is written from a Dutch utilities perspective but the reasons can be considered on a European level.  The advantages of this technology versus the drawbacks for the consumers.

Continue reading " Why consumers don't want a smart meter " »

The pitfalls of Agile software development

Since the late 1990's several methodologies for developing software have begun to get increasing public attention. Each had a different combination of old and new methodologies or were evolvements of old methodologies. But all emphasized on close collaboration between the technical team and the business experts; face-to-face communication leading to short communication channels and less misinterpretation of expectations. Software is delivered on a more frequent basis and each delivery has business value in mind. Teams are self organizing; roles are clear but also interchangeable and no hierarchy exists.

Continue reading " The pitfalls of Agile software development " »

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter