Aug 30, 2015

Internet of Things

"The Internet of Things (IoT) is a scenario in which objects, animals or people are provided with unique identifiers and the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction." -

But to me Internet of Things is thinking smarter and smarter and smarter. Once you start using smart devices and explore App store, your imagination grows. We as a human being have power of imagination to see things before they happen, we have tools, devices, and infrastructure to support our ideas: smarter search, smarter marketing, smarter shopping, smarter payment, and even smarter cities.
Devices we use are not only better engineered but also possess huge artificial intelligence. Devices from phone to TV to car to everything. Everything means everything, and these things can talk, exchange data, generate reports and decide our next delight.

The Internet of Things moves beyond Machine to machine communication, which involves smart devices. IoT provides IP address to every thing possible via IPv6, which was developed to deal with problem of IPv4 address exhaustion. IoT facilitates communication between things over network.
In recent times we have seen huge adoption of cloud combined with heavy analytics on huge data.
Software industry is mature now with proliferation of applications from every part of any industry to every device to more and more humans. Ever growing number of interconnected devices, continuous data exchange, big data storage and analytics have lead to new avenues in Internet of things market.

Why IoT is so important today is because timing is so perfect, smart human and even smarter devices, intelligent applications on cloud, big data analytics, and ever increasing demand. How we see world today is in right image from WordStream.

I worked on smarter planet project by IBM for Europe, where you develop load shedding zones within your home by applying multiple sub meters and decide on switching on or off group of devices, and this project was done in year 2009.
We have moved to a point of Body Area Network (BAN) with smart watch, smart t-shirt, and smart shoes to name few. It's all about imagination. Human minds build cities, human minds build Internet of Things, and can build Smart Cities. When we study more and more we build imagination more as we build our imagination on top of others, that is what happened with me too when I read more and more.

Its time for new age innovators to think of new things, or combine old ideas with new opportunities. IoT brings opportunities for engineers, managers, digital officers, entrepreneurs, businesses, consumes, and everyone.

Hype is snagging IoT, no doubt when we imagine beyond expectation we are in hyped world in which we think machines should decide government and a world without loose basic values of emotions and morals. This is reason why recently release IoT manifesto includes Hype as the first point.

We are at the centre of a universe of devices, laws, practices, procedures, etc., but good thing is they are now smarter and connected, they don't live in isolation, they dont need us to facilitate communication and best part they can communicate with us and we control them.

If you look for ten technologies around us that make Internet of Things, you will find below from CNET or Telegraph or Google:

Behind the scenes are technologies that making these things possible. Its a parallel universe, where every object - people, self driven cars, smart appliances, etc. - make then selves recognizable, they comunicate, and make intelligent decisions. I am not talking of just IP, AI, 4G, or Big Data; I am talking of summation of these all.
Communication technologies 4G, Wireless Sensors, RFID, M2M, etc. enable IoT. IoT applications will provide control over a network: a network of home appliances, Office AC system, Telephony, Home Security, Electicity Grid, Package & Delivery, etc.


With time we are making progess in - Highly connected networks, IoT applications, Infrastructure, Cloud computing, Big Data Management, Security, Devices consuming low energy, and Standardization - we need to continue making progress for early success and early adoption.


Aug 18, 2015


Sprint is generally 2-3 week event, but can be of 1 week or 4 weeks too, to develop some user stories. 
Below images give some idea on Sprint. It starts with Sprint planning, in which we choose the user stories to develop and ends with Sprint review in which we review what we have done.

"Scrum Framework" by Source (WP:NFCC#4). Licensed under Fair use via Wikipedia -

"Scrum process" by Lakeworks - Own work. Licensed under GFDL via Commons -

I am working on totally Agile project using Scrum framework and since everyone has his or her own way of doing things, the Agile is also bit twisted by everyone to adhere to a organization goal. My ideal way of doing a Sprint is 3-week Sprint.

Sprint Planning
Before start of Sprint we do Sprint planning with big motive of coosing user stories from product backlog and placing them in Sprint backlog. In Sprint planning all we have to do is choose user stories. I have found that initialy people show interest in these planning sessions, but later on these meetings become boring.
Choosing User stories is collaborative effort in which user stories have priority but its development team that chooses the stories they can deliver and User Stories are ready, its important
At the end of Sprint, the chosen user stories should be in done, and if not they can be part of next Sprint. A user story with done status can have a attached evidence, such as a user story of delivering login screen, can attach a screen shot of login button.
I have seen some scrum masters suggesting standard way for deciding story points, but I disagree I think poker session is fun part of Sprint meeting. A story point is like T-shirt size which is based on more on complexity compared to time because we are working in time box system., but its size. A better explanation is on -  If a user story is big and can't be completed in a Sprint, it should be further broken into multiple user stories, but a user story doesn't contains user stories, it contain tasks. Epic is broken into multiple user stories and a user story is broken into multiple tasks.
A Sprint is created with Sprint backlog at the end of Sprint planning. In my experience user stories are all in To-Do status right now.
Throughout the Sprint the development team can update the Sprint backlog.

Daily Scrum
15 minutes meeting where every developer (not scrum master or product owner) answers below questions:
What did I do yesterday that helped the Development Team meet the Sprint Goal?
What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
And development team member asnwer to complete team not to scrum master or product owner. 
I generally manage the daily scrum call, what I do is when I send meeting invite I also send above questions in the meeting invite, so that developers are ready with answers. Developers one by one, in alphabetical order, update in meeting by answering the questions. For a global team we used WebEx to conduct calls at fix time 1 pm everyday for any Sprint. We talk only about one sprint, we dont know at what time or where daily scrum calls will be arranged for next Sprint.
(Image Source -
Big point to note is we dont solve any problem in this meeting, but we do mention any impediment we face or see.

Sprint Review
On the last day of Sprint or after Sprint we do review, Sprint Review, which is an Informal meeting to present what was done in Sprint to scrum team and stakeholders. Generally presentation is of increment and feedback is collected along with answering any questions raised, and meeting should not go beyond 4 hours.
Sprint review session begins generally with a presentation in which Product Owner discusses what is done and what is not done, development team demonstrate the work done in sprint, a tester might give testing updates, development team member can give details of governance activities, and product owner can present product backlog.
A preview on what to do next and input for next Sprint planning; review of goals, timeline, and budget; and revise the product backlog.

Sprint Retrospective
"The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint" -
Sprint Retrospective, a max. 3 hr meeting, is done after Sprint Review and before next Sprint planning.

It is also mentioned in scrumguides that
The purpose of the Sprint Retrospective is to:
Inspect how the last Sprint went with regards to people, relationships, process, and tools;
Identify and order the major items that went well and potential improvements; and,
Create a plan for implementing improvements to the way the Scrum Team does its work
In my experience we shared on wall three columns:
What went well, What went not well, and What do we want to improve.
The columns can also be named as with meaning nearly same:
What went well that we want to continue, What we can do diffrently, and Action Items
Each development team member asnwer these questions such as one below:
 After taking inputs from each development team member, each development team member can vote for say three action items (What we want to improve), which can be included as User Story in next Sprint.

In a typical Software firm we dont just deal in development and meetings, we have lot of surrounding activities, which are lot more critical. A sprint is not only abouty development, we have look after testing and delivery too along with lot of governance activities and documentations.

An ideal scenario - 
An ideal scenario is a successfully implemented Agile project. I have seen a project in which we had delivery every three weeks
Lets summarize by this self explanatory image by "The Scrum Master Training Material"
A sample project plan with Sprints

Aug 17, 2015

Architecture design in Agile

"Architecture evolves" is the key word in Architect's mind while in Agile. Architecture is a set of features (Architecture Features) on which business features are developed, and its collaborative iterative design.

Architecture Design changes begin with one or more Epics. Architecture Epics are decided after an brainstorming session or architecture epic kanban system.
Next step is to decide one which first probably using WSJF, identify risks, discuss with business and architects, and define success criteria - all can be document in concise Business case document - optionally. Approved Epics go in backlog. This is done before Sprinit 0. 
After initial planning involve developers, and throught program Design is iterative.
Developers and Product owners can design too and if required get it approved from Designer.

Throughout the project, designers should be involved in Sprint planning to make decisions on product grooming.

A big move from waterfall to Agile is in Design approach where previous suggested final design and wireframes but later suggests iterative design and UX, similar discussion is on

Sprint 0
In Sprint 0 we have opportunity to decide on what to be developed in Sprint 1. Get fundamentals right before a time box even - Sprint 0 - starts; therefore First brainstorming between product owner and architect must be done before Sprint 0.

Notes for Evereyone
Design is not final and do not wait for wireframes
Design is not done in vacuum.
Bootstrap - services, build, and UI - initially, if design is not ready
Designer should start talking early to everyone - Product owner, manager, UI, UX, etc.
World doesn't needs Minimum Viable Product
Talk, talk, and talk with everyone

Architecture features are implemented incrementally and implemented by Agile team. Architecture features complete the business features and they also originate from business features.

More to designers
Advance HTML, CSS, and JavaScript allows us to prepare attractive UI, which combines with business features to finally become a delighful product, which also happens to be our aim; therefore we should not wait for wireframes and start working on most delightful product.
Product owners and developers are part of Agile team and they can too design, so they must be provided with enough knowledge and tools to make changes in design if required.
UX designers should start with sketches and designers should start with tools.
Big Design Upfront, Minium Viable Product, Non technical person, etc. are gone definitions.
A light weight modeling at the start is Architect's envision to identify risks and critical points.

Question for SCM 

What are two (2) ways a Development Team can ensure a good application architecture?
The Development Team should have a set of guiding architecture principles that every Development Team member understands and follows when writing code.
The Development Team plans some time each Sprint to discuss the architecture needed for the features planned in that Sprint.
There is no specific "architect" role on a Scrum team, nor is there an architecture planning Sprint.  But, a good architecture doesn't just happen automatically.  Guiding principles and frequent conversations on the team help ensure that the most appropriate architecture is developed as it is needed by features being developed in the current Sprint.

Who is responsible for the system architecture of a product being developed using Scrum?
The Development Team.

When is a system's architecture decided?
Throughout the project, as understanding emerges and the Development Team learns more about the project.

Architecture spike?
A small development activity to learn about technical elements of a proposed solution

Big Agile Picture
(Source -
On site you can click on any icon and get more details.


Aug 16, 2015

Scrum of scrums

"A technique to scale Scrum up to large groups (over a dozen people), consisting of dividing the groups into Agile teams of 5-10. Each daily scrum within a sub-team ends by designating one member as "ambassador" to participate in a daily meeting with ambassadors from other teams, called the Scrum of Scrums."

A little more investigation on finding coordination between several agile teams, "scrum of scrums" is the best solution. 

A typical Scrum team is five to nine people. Rather than scaling by having a large team, Scrum projects scale through having teams of teams. In this way, we have worked on projects with more than 500 people and have consulted on projects with more than 1,000. This also means several product owners and several scrum masters, along with chief product owner and chief scrum master.
Although it's not the only thing necessary to scale Scrum, one well-known technique is the use of a "Scrum of Scrums" meeting. With this approach, each Scrum team proceeds as normal, but each team identifies one person(a technical contributor on the team rather than product owner of scrum master) who attends the Scrum of Scrums meeting to coordinate the work of multiple Scrum teams; if 4 or fewer teams then 2 person – technical contributor and scrum master - can join from one team These meetings are analogous to the daily Scrum meeting, but do not necessarily happen every day.  It is recommended that this meeting be time boxed, like 15 minutes, and daily; but if meetings tend to be longer like 30 to 60 mins then 2 to 3 times a week should be sufficient.
Scrum of scrums generally suffice all requirements, but scrum of scrum of scrums is also possible though it sounds silly. A problem identified during meeting should be addressed, because it might be affecting work of 100 people. 
Agenda of “scrum of scrums” can be same as daily scrum, but Mike Cohn suggests below agenda, if meeting is not happening daily –
  1. What has your team done since we last met?
  2. What will your team do before we meet again?
  3. Is anything slowing your team down or getting in their way?
  4. Are you about to put something in another team’s way?
After every team member answers 4 questions, any problem identified are resolved. Backlog can be maintained of problems identified.

Scrum of Scrums are so effective that other meeting such as status meetings with managers should be discontinued. In many companies we start with one team, but as team size increases such as from 6 to 18, we need to split and create multiple teams and immediately start scrum of scrums with a board, as is a case study mentioned in
Representatives from all teams gather in a room with board with three columns: Issues to resolve, Resolving, and Resolved. Its not necessary that all teams send representatives in the first meetings, but with time more and more teams can join “scrum of scrums”; more important is right people join the meeting, either developer or tester, and a scrum master facilitates the meeting chosen on rotational basis. Its not a program level meeting attended by managers who are not doing work, instead its for people doing work to discuss and resolve issues across teams.
So, its not meeting scrum masters where they will discuss status. 

So we can understand what details about "scrum of scrums" is mentioned on Agile Alliance - Its normal daily meeting where ambassadors report completion, next step, and impediments on behalf of team they represent, and problems identified are maintained in backlog.

Jeff Sutherland also suggests that "scrum of scrums" is responsible for delivering the working software to the definition of done either on specified date or multiple times a day.

© Technology Development with Java background | All rights reserved.
Blogger Template Crafted by pipdig