Tag: agile

Categories
blog Videos

SDET a step towards creating a self Organizing team…

https://www.youtube.com/watch?v=Q9Id9jUj10w

Who is an SDET ( Software Developer Engineer in Test / Software Design Engineer in Test) ? Initially started at Microsoft many companies have these job titles these days. Watch a short video on how this role forms one step towards moving self organizing teams. A pure tester alone or developer alone role is fast fading and instead one needs to be a mix of both. End goal is to ship highest quality code just as in engineering , we cannot say that the bridge has only 50 % quality , the engineers lacked focus when it was built. Similarly SDET is redefining the software engineering practice.

Categories
Videos

Techgig Talk : Why should you care to create a Reference Architecture In Your Organization

Key Take Aways from the Presentation

How to relate to Enterprise Architecture Frameworks such as Togaf and Zachmann and make it work for your in your Organization ?

  • Why do need an architecture in place in a product or solution ?
  • Why are different views to architecture important and why is important to create the one that you are interested in ?
  • How do you apply framework level separation of views to create a reference architecture ?
  • What is the role of architecture vis-a-vis agility? How much architecture is needed for the hour ?
  • How will people in the organization benefit from having a visual representation of architecture. It is there for all to see.
Categories
blog

Centralize Interoperability and Decentralize Implementation

decentralize_implementation

Most often in Organizations we have a crucial process that most often is referred to as governance or project monitoring or simply operations at times. What this means is to look for facts and figures and data in the system that are not aligned to the organization vision / mission long and short term and set things right. Do what is required to set things right including pulling one’s hair out / fire fighting or simply status meetings and reviews. In the midst of all this various governance / steering committees are created which acts as custodians or guardians of organization know how or the gatekeepers keeping a vigil on how things are done.

Turn your developers into Rock Stars and Managers Into Rock Star Promoters is an other way of saying give developers the freedom to do things that they do best and let architects/managers do what they can see and the developers cannot see. This means things like getting an approval for a module specific change deep down in one’s own code ownership should not involve going around people to get approval. Decentralize these kinds of things in the organization with adequate code review / test unit process and ensure overall sanity of the changes. We do not need much effort on this front to set things like this rolling. Whereas lets say there is a change that crossed two product solutions / interface and involves a messaging layer change or impacts one or more teams solutions. In this case Centralize this Interoperability aspect and ensure the stakeholders from both sides are involved including people with the right skills required to take the decision are present for deciding on these changes. This way architects/managers or senior members of staff who are capable of taking a decision on this should be involved in such decision committees. This ensures there is less red tape in the system and more control at the same time where required and adds value.

Saves Time / Money and Precious Organizational collective time : At times every organization gets caught up in first setting up a process and then breaking the law themselves when it becomes too rigid to follow. Review your process every now and then and follow this principle to eliminate waste occurring due to collective involvement of people not really adding value to the process. Also this would promote organizational flexibility and agility where people go ahead and make changes confidently , check in the code and prevent show stoppers in the pipeline. Remove the barbed wire/fences here would ensure people feel encouraged to owning things up and cleaning up their act. Instead if we route all things important via a central decision making body then it is invitation for disaster. Developers who shy away from meetings will not be ready to even raise these issues fearing a meeting with all and sundry and having to explain the rational which may not make sense to others. Yes empower them and also ensure that the are enough code review processes/checklist for various modules/process which people are following. Also the source control repository should have details on who checked in code/artifacts and back trace it with a  ticket tracker. Once this is there in place then let loose the need to monitor every thing that goes around. Instead use this time to review things that span product interface boundaries , cross solutions where there is a real need for tight control and strict governance.

Release the barbed wire around your teams and let people contribute/own things and co create greater good for the organization. At times it is good not to have any formal authority and works well in smaller teams where agile practices are practiced and but this concept can be extended for an extended enterprise which would be agile at scale scenarios.

Categories
blog

Why Sign both the Manifestos Agile and Software Craftsmanship ?

signhereorthere1

This question is more like you what if you were asked to sign for two rival organisations one pitted against the other. In a communist regime it would be akin to siding with the dictator and other with the rebellion groups at the same time. On one hand we had the agile manifesto which brought to the table best practices of XP which later took over to Scrum and now there is movement called Software Craftsmanship which is gaining momentum. It was always there but it just that it is resurfacing itself with more necessity now. Need a Surgeon who follows all the procedures correctly and also does a good job of the surgery. This is how we need to see both these movements Agile and Software Craftsmanship movement.

What is Agile manifesto ?

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Remember the initial agile thing  that we got to practice was that of Extreme programming and it sounded as if we were doing something out of the way. Not certainly new things but old things in a newer faster effective way. It got people involved in the whole process and brought a lot of mileage and visibility in the organization. A little later came Scrum and other lean and mean characters followed.

While all of these got practiced by people , the craft of delivery good software got lost along and it became more of a process rich methodology with backlogs, sprint run race velocity and a lot of jargon thrown along the way. We left the main essence of all our work which is to write good software aside and got carried away by all things agile. Little realizing that if we sulk on writing good software then it will eventually slow us down no matter agile or otherwise.

Just as we have good engineers doctors who take pride in laying a state of the art bridge or performing complicated surgery , an expert software person these days is almost dealing with the same set of tools and many a times doing mission critical jobs which are at risk if we leave the craft aside and focus on delivery alone.

 What is Software Craftsmanship ?

  • Not only working software,but also well-crafted software
  • Not only responding to change,but also steadily adding value
  • Not only individuals and interactions,but also a community of professionals
  • Not only customer collaboration,but also productive partnerships

Why we need Craftsmanship in good measure along with Agility ?

Technical debt increases in the project as it progress if the initial thought process to create an architecture which forms the bedrock promoting flexible changes end to end is shallow and not done correctly.

Most often we know how quickly we ended up doing a POC or the initial releases of the product. As we progressed things got slow to the point where there were instances where a customer wanted a font change or a logo change on some index.jsp but we ended up saying it is going to take some obscene amount of time citing organisational procedures, bureaucratic red tape , QA , testing of all forms , our platform certification practices etc. This is true of even the big boys when we request a small change in any software of enterprise level, all we get to hear is yes we have considered it but gives us time till next release and we will put it right back in there. All of this is familiar to most of us when things looked quick doable in a jiffy but as the product matures ,egos rise and technical and product debt increases we find ourselves like the rain starved farmer looks at the skies for divine intervention. This could have been avoid if we focused on Software Architecture best practices and craftsmanship of some form. The better the skill less is the debt . We have existence at all levels so we could have various forms of craftsman some more skilled than the others and others not even acknowledging that there needs to be one on the team. If we do not pay heed to software quality and design principles , architecture best practices , code best practices and correct things then and there we will be debt ridden and eventually end up with the debt being written off meaning scrap the product line and look at rewriting this.

There was this joke going around in one of the companies , there are 50 people working on re-factoring the product and the unofficial hear say was you need half the time and only 15 people to rewrite the product completely from scratch. Most often you cannot digest the fact that scraping something altogether is worthwhile , just as we have an old item in our house that served its purpose but now occupies space and does less. Of course while we value that it served us well and enabled us to get this far and when we want to do something different then we should be able to redraw our priorities and align our needs accordingly. Writing good software is an art with more of a process like if we get X people certified on Y technology then we can reap Z benefits over a period of time. This rarely works although most often this gets practiced everywhere. Just as of all the people who learn a language only some manage to write poetry that can move minds and souls. It may not be a good analogy as we have fewer poets than software engineers these days.In a similar fashion while we need agile practices to help us quickly add scale to our operations we also need to have the craftsmanship part of it to go hand in hand. Else we will have a process rich methodology without craftsman who can execute on the promise of the Agile story. We could look at in more detail what constitutes craftsman ship in an other thread.

So sign up for both if you want to sow the seeds as well as reap the rich harvest.

Categories
blog

The loser takes it all , failure is so welcome

failure_not_an_option     

Keeping Failing But do it Fast – Projects / Pet Agendas and Companies 

No option to fail , serious problem. Not failing not quite true anymore ? …This is sounds quite a ridiculous statement more like saying that if you wish to live forever then you should be prepared to die any moment meaning for a cause then you become immortal and then you live forever. The only way to remove a thorn is with a thorn. Does not mean get pricked by a thorn to remove one. What it means is if you the quicker you fail the faster you realize why you failed introspect and move on. Yes inspect why you failed and move on. What this goes on to state in so many things in different facets of life.

Software Projects : You have a mandate from product management on some feature that looks cool in the market and have been asked to roll it out without questioning authority. This then leads teams to prototype it and then check what are the pain points involved before you can say it looks ok to go ahead or not ok. This means you have imposed an increment of work unit which is short time boxed and you come back with your conclusions or state what is possible and not possible in black and white. At times the shiny new thing on the tools available might force one to think that it is the way to product stardom etc. But once you have developers dig their claws into the library or framework it can really reveal whether the framework really promises rapid application development or it is just another cool thing but not so cool when really played around with. Once you get used to failing every now and then you get to learn a new way of handling things in small iterations. This reinforces one to believe that failure is after not all bad in fact we are now more knowledgeable with all our combined failures put together. When someone says we trying out that thing in the market you know what that means and know your way around it . Fail fast is the new world order. It was always like that we never noticed it enough. So all such truth lay hidden reveal themselves to us when we move around try new things and fail , yes fail. Once you know it then the other side of the coin has success embossed on it . The trick is to identify it first and get it right. Know you have failed and that too fast. Do not worry about the project estimates going for a toss , put them with the knowledge that there is going to be 20 % this way that way to it. The message is don’t aim for perfection keep failing and refining.

Pet Projects : Read some where that what ever was in your mind a while ago is now on TV and leaves you thinking that “Oh Oh that was my idea for my pet project” . Do not keep them so bring them out do what you can do to flesh them out bring them to reality else they remain pet projects. This principle also translates it into a fear principle. The guy who has failed first becomes more successful. School dropouts can only create a Microsoft , Facebook or Oracle. Do not keep anything a pet project is the moral here.

Companies : With everything lean and mean a company now unashamedly keeps on revising its mission statement from time to time and does not think twice before changing course many times during the day instead of months or years. Earlier you needed the big consulting companies to say where you are heading and when to turn left and right. Now most companies seem to follow the agile way of doing things and shorter project iterations reveal what we need to do eventually with the product , roadmap etc. So when the failure principle is inculcated into teams , individuals and then the company culture then it becomes easy to drop your opinionated theories and see for yourself in short cycles and tailor your turn around quickly.

What it means that the more agile you are more prone you are to repeated failure. Stay agile welcome failure in leaps and bounds.

Categories
blog

Testing game is about to start are you ready ?

areyouready

With the development team’s task over now the task passes on to the QA which is a critical leg in the project. In fact they are the last sentinel on the way to the software trying to make or break its way into the release shipment. While QA could work hard to find and unearth bugs and issues which otherwise might lie hidden under the labyrinth of the product / application. It takes more than just skilled developers doing their best not to plug in errors into the system.While find bugs , code reviews and umpteen number of best practices would ensure that we produce a great piece of functionality or product which is always ready to be shipped the day QA bless it.

Testing a challenge a skill a craft and not something that is easy to do. It is a forte of a chosen few who do their best to go under the hood and look for the spanner left over post the tasks. It is like a doctor who would have performed a successful surgery but left a knife in the patients body. Testing if done right can trap these defects and help plug these issues.

From a tester’s standpoint what would be important ?

1. Many a times a viewpoint/view that he is looking at is not available in document format anywhere in the organisation.

2. No proper handover of what goes into the software if the developer did his stuff and left early to catch the friday nights bus.

3. No diagrams to illustrate what is that has changed in the organization big picture. He is told things like “we have improved security in the system now”. What does this statement leave the tester with unless told what was really introduced as a part of the fix or change.

4.Does he understand what needs to be tested and does he have the tools.

5.Does unit testing/TDD cover what is to be certified. Or do you always need a full product end to end scenario testing.

6. How much of automation do you have in the system ? Are the test cases all automated and effort being made to check if the code coverage is 80% and above. Do we need to up this number ? . Are we getting false positives ?

7. Does our code coverage make us happy whereas there turns out there is always some boundary condition that missed our attention?

8.Do you have a proper architectural artifacts documentation strategy where QA can go look at it and figure out from time to time where the product is heading ? Most often we have it was last updated when we went for that team outing.

9. One of the ways the product gets to have a feel that all is well in the system is a reiteration their documentation and diagrams are updated and understandable by one and all in the system. This mechanism needs to be continuously followed for everyone to sub consciously starting to feel that our mechanisms are what it should be. If not there we fix them when found. Any other feeling here will not reinforce the “right way” among people.

UML is understood by techie crowd whereas we need to have a mechanism for ensuring the business,functional folks and non technical folks also understand the system to touch/feel/breathe the system and own it as much as the developer who put pieces in their. All of these need strong mechanisms for documentation and diagramming/some kind of non ambiguous visual representation of the system/product.

Go choose your diagramming strategy and be ready for any challenges on your way. It is always better to document things even for preparing for agility. On one hand as we always prefer working code than elaborate documentation , it is equally important to have a proper mechanism in place that works for you. That is where the question of just enough comes into play go for just enough documentation and visual representation.

Ultimately software delivery is a close knit game where all need to play their part and not simply passing the baton from one team to another.

Categories
blog

Project in Auto Mode (Scrum) . What do I do as a Project Manager ?

roleofproject_managerin_scrumMost often companies embracing agile practices go through different moments of self truth and stories of shifts in thinking and the experience that can be termed as close to realizing your true self. All the while having been used to a set way of doing things turning agile is almost equal to turning a new leaf in your life book. It needs very strong management involvement and commitment from all the stakeholders to make it a success. It is a given that people understand what this means and act accordingly to achieve the end objective. 

Scrum teams are self organizing : What does this mean , it means they know what to do how to do and how much to do in a particular iteration. Lets keep this simple for now meaning we all understand the basics of scrum  at some level that it is refined quicker and leaner and meaner version over your traditional project management practices. Now there are various key role in the scrum iteration or sprints as they are referred to. As per scrum principles there exists no project manager with a title at least in formal terms. What do existing project managers in the system do ? Go find a hobby of their liking and pursue it or go on a short sabbatical and be back when required.This again depends from organisation to organisation how the role is defined and what roles a manager typically plays over there.

Project Manager in smaller organisations

If it is a small organisation or setup then a project manager gets to play the role of the scrum master or product owner. He/she clones himself into the roles of a scrum master or product owner and plays his part. Ideally you should not mix and match product owner and scrum master as the focus each role has is different. Here again it depends on the maturity of the organisation or the luxury of having dedicated roles if the team size is considerably small. There is no set rules here just because your into agile or scrum does not mean your are fully agile or aren’t. Companies take time to achieve this state over a period of time and it is not overnight.

Scrum Master : Involved with the team coordinates with external parties and ensures team’s voice is heard well outside of the scrum discussions , is responsible for the outcomes , resources and people. He is like a project manager turned well wisher of the team who is not seen as someone who can be career limiting if you cross swords with. A refined project manager with strong head balanced over his shoulders knows where to give the team its due and is finally accountable for it.

Product Owner : Interfaces with the team for things outside of the team as a single point of contact. Defines the product / project scope , prioritizing the items of the product backlog. What gets done now and in future iterations? Speaks for the end user and wears the customer’s hat.

Scrum Team : We are the new kids on the block who do not need to be told what to do. Everyday we meet and exactly figure out what each one fills up his plate with. We do each share others burden and know where to meet each day and say hi , hello to all in our team at a fixed time thanks to scrum else we would be brooding next to our monitors pretending to be immersed in work having no time for meager social protocols.

Project Manager in bigger organisations : Here the role of a project would be that of managing expectations of external stakeholders , planning resources , budget , team transitions , resource transitions, talking internally / externally to other teams and interfacing with them to create a organisation best practices / repository of information. Appraisals for the team in coordination with the scrum master.Taking receiving feedback from resources who are now not directly reporting etc. There are various other things he could be involved in such as following up on release closure activities of previous cycles ( agile or non agile as the case may be ). So simply it means that every time there is a change people get pushed and moved around and challenges everyone’s status quo. Accept the change move ahead all get to play there part and scrum is not the red revolution around the corner once things have stabilized and the initial resistance melts down.

What is there for us in a scrum / agile environment ?

In fact all of this requires the entire team / managers to be geared towards preparing for what is expected of their teams. Mailers , tech talks and other organisational propaganda , brown bag lunches all help here. In fact the question for all would be what is expected of oneself as we go through the churns in a scrum or agile environment.