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

Leave a reply

roleofproject_managerin_scrum Most 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.

Want to be an Architect , can’t see ahead , what to do ?

Leave a reply

This a question that pops up in the minds of most people who take the technical route instead of the managerial route or business route after having spent some years of significance in IT. This reminds one of the snake and ladders game where you are playing your cards/dice well but are eaten up due to the monster snake on the path( existing commitments to projects or routine organisational activities). In other words you are simply not able to get time to do the things that you wanted or enrich your skills to the climb the ladder and be an architect. Always bogged down by existing tasks and they do not seem to break free instead keep adding up letting you loose grip of things. Most often we have people saying I need to get into that role because it is more challenging as opposed to what I am doing current. Grass on the other side looks green and shiny each job has its own issues and challenges. The way to work towards a career in architecture would be join linkedin groups focused towards architecture. These days there are many right from data architecture,cloud architecture,enterprise architecture,software architecture,security architecture and so on. Just as you would have made a choice of on your electives in your college stick to one and then pursue it. Drop by blogs , research papers, developers networks, communities, forums and join people who breath the same air.

There are tons of free videos on youtube on this topic and more goggling will get you better focus on what suits you and your existing skill sets. Most often get asked the question in some workshops ,by participants that “I want to be an Architect but my current job has not enough provision to extend my capabilities. Here is some quick things that you could do on that front.

Create your destiny :

Hack1 : Volunteer for activities outside of your work that get recognized as architectural in nature. Fixing analyzing issues, adding a new skill to your tech skill , participating in code reviews, design reviews and demonstrating that you just not know your pieces well but do understand the whole pieces and how they stick together.

Hack2 : Participate in showcasing your skills such as presenting or giving a tech talk at an event internal or external. Get people to listen to you using such forums.

Hack3 : Follow them on twitter , linkedin stalk them 🙂 . Read what they have to say and how they evolved from developers to their current state. Many will have a of them have funny sides and you can find yourself in those positions as well.

Hack4 : Attend boot camps, developer summits workshops which give you an outside the arena view of things in your topic of interest. Gradually incrementally add little by little to that body of knowledge.

Hack5: Think you have already become one and act like one. Fake it till you make it. You may not have genuine goodness in you but they say initially fake it till it becomes a part of your being.

To be good at something you need to follow the famous principle along with the above hacks “To master something, you need to spend 10,000 hours doing it.” Ask yourself have you put in that effort or are you expecting things too early.

It is a different story that also goes around ” I am architect but do not know what do to”. That is the topic of a separate discussion.

Create your product roadmap radar

Leave a reply

Most often in organisations we would want to create vision statements on certain capabilities that we want to achieve. At times this is in full display at coffee stations , common meeting points and in the stairways. At times these are simply in the form of certain xls sheets or mind maps tools which gets debated endlessly and post consensus are put down in ink on what gets on the plate first and what will be consumed later. All of this has umpteen rounds of discussion on what looks better and is lean and mean and is doable in a certain time scale. Most often what is seen of very high impact is what drives user experience lets say improved UI tools to solve the customer pain points in terms of customization / deployment or integration issues. We may have tweaked a certain algorithm deep down in the code which may improve database caching and save round trips end to end and improve performance. But this can at times go as a should have been done in the first place theory and what delights the customer is what he/she sees to use or touch etc. So it is beyond reason to debate what the customer likes and catches his attention. Most often have heard old timers whom I worked with saying customers were happy with character based terminals instead of browser / web enabled mechanism which improved tech quotient of the software but greatly increased the time taken to key in details to punch in a transaction detail on the screen. The customer in this case doesn’t care if you used jsp/ROR/Scala/Coffeescript/node.js or Ajax or html etc he is forever cribbing on missing his character based system. He was quite accostomed to inputting all of this without leaving his keyboard and now he needs a UI to distract him and has to leave the keyboard to do most of his tasks. You can justify saying we upgraded you to the latest technology but he would say a different story , you downgraded his precious user experience. This is beyond us when we are onset with different challenges to embrace the shiny new thing on the block at times driven internally, at times forced by a customer, at times marketing and sales driven. So in short we most often from time to time need to check what looks good on our roadmap or radar.

Build your product roadmap/radar

Was reading an article on the same from Neal ( Thoughts works ) on how they build a technology radar . Could see that this can be used in many organisations not just as a technology radar and in fact as a product radar to paint your picture to your folks. Most often this exercise is tough and challenging as now if you as a team commit to doing something and is on the radar then it is for everyone to see and measure where you reached. It brings people to commit to items on the product stack and keep them motivated towards their committed items. Of course you would need other factors to keep people motivated and that would be another story. For now lets say it helps people to focus on the vision statement and keep them hooked to it.

Lets say we could apply this radar to a product roadmap. If we were to consider our product to a banking software tool , since I have worked most time on this domain. Lets say we have different product divisions (Corebanking/CRM/Channels/Treasury) internally in the company that wants to track their progress and what looks good going ahead and what needs to be watched , what needs to be dropped. With our fascination for quadrants and the following radar mechanism is handy to view where you want to go and provides a pictorial representation behind all the discussions that went into making this chart happen.

There is a nice explanation on the whole process of making the radar on what the different arcs represent such as nice to haves, must haves , trial and error pieces for the period and on hold items. All there is a nice thing that if you see some items as not having moved up the discussion from nice to haves to must haves then they simply fade away. Can be re blipped when needed back on the radar. There is a nice little tool https://github.com/bdargan/techradar for plotting your radar which uses a JSON format structure details which internally uses polar co-ordinates to plot the radar. On the process and the details of how to arrive at this radar in your organisation Neal’s article is a nice read. on the thought works approach. My personal experience has also been same in terms of the consensus approach finally the person closer to the technology or the domain guys to have a major say. This apart if it is a pressing need from product strategy or marketing then it overrules all.

Go ahead build your own radar and it would be nice to hang around places where people spend time most else it will simply become a vision statement without follow up.

Summary Execute Execute Execute – Message from StartupCity2013

Leave a reply

Was at the startup city 2013 NIMHANS Bangalore yesterday. Was fun/motivating/inspiring to hear from stories of struggle and eventual triumph hitting blocks and then tasting success at all scales from small medium shops to big success such as Chetan Maini ( reva fame), Arun Jain ( Polaris) , Cric Info founders , Gaadi / Galaata founders. The air smelled of entrepreneurship and Silicon India organized it paving a way for an ecosystem where like minded folks gather and discuss ideas big and small.

Listing down a few key takeaways which are eternal in nature and many echoed the same.

Chethan Maini (Reva) ( Be passionate about your work) . Money is an offshoot of your work. It is OK for people to laugh / not agree with your idea initially but believe in yourself.

Arun Jain ( Polaris)

Team building is being part of the team and not merely leading the team. Feel as if you are one. Have many ideas what to do ? Stick to one idea , eat the idea, sleep with the idea and get up from bed with the idea and you will find success.

Padmaja Ruparel ( IAN Network)

A class B idea with a class A team is better than an class A idea with a class B team. Finally execution , execution and execution alone matters.

Balaji Parthasarthy ( SnapFish)

Know what works for you and a team is better than an individual as more energy and diversity is put to use. Of course single founder exceptions could be there as well.

Many people think on the same lines finally whoever sticks or believes in their idea and takes it to conclusion gets the slice of the cake ( angels/VCs included)

2 Minute Elevator Pitch ( Tell me what you do in 2 minutes product/team/company etal )

The best part of the program was each startup was given a 2 minute elevator pitch to drive home the message what they do. Some performed great in the act and some still taking baby steps in their companies and products did not do so well although they might have great products. Overall no idea is mean or small there is a potential in everything that solves a problem or a society’s need for something.

Meet the VCs

You did not need credentials to meet people to fund your ideas there were separate rooms for finding people to fund your ideas and evaluate them.

There were people other great people who were part of open discussions and finally the CXO conclave at the end of the day sharing their stories and thoughts on tech entrepreneurship in India.

Overall the event was great and nice to breathe the same air as that of the founders and CXO’s of various companies big and small under one roof. It was definitely worth hearing to many young turks who are on their way to creating something great and of value to the society. The startup culture is on its way and as per discussions now India is only way behind the bay area in US in terms of emerging startup scene. It is good to get yourself in there and get rub shoulders with a crowd who stick out and ready to tread a different path to achieve the destiny of their making. If you are not creating something then you cannot predict the future. Nice to know that alongside all the hard work and passion behind the scenes some sweet smells of success of companies could be smelt there. It is good to get the aspiration of people high by hearing of folks who have done it once/twice many times before you. You get a feeling that it is after all not something only a few could venture into…

Nice hangout on a saturday came back feeling Bangalore is happening on many fronts.

Put your Release and Build Team to Sleep….DevOps is here

Leave a reply

With a backdrop of the traditional waterfall mechanisms of project management, build and release was always pushed aside as the last but one activity before cutting the CD / testing certification of the software. The last mile as it was referred to this although was the last step in the journey towards a software delivery it would remind one of the famous lines the “Journey has just begun”.

Although this was the last step supposedly to be taking 20% or less of the actual effort it generally would be the other way around , taking a significant effort and often not scoped in estimates and it was quite OK to do so till recently. Start the blame game and developers blaming QA and vice versa and everyone including the other teams would take potshots at each other and say their part worked fine but the had issues in the final integration. All of this started to be stage managed with late nights and weekends going into getting all pieces talking to each other is all very familiar with traditional methods in place.

What next ?

There are some best practices such as the following that are being followed where everything is continuous meaning

Continuous Delivery
Continuous Integration
Continuous Deployment

What all of this means in short is every time you change any part of the product the whole SWAT team runs behind the scenes to check if all is OK with the system. Now if someone were to check in something that breaks the system then it needs to be fixed then and there. Have seen that code needs to be fixed corrected by the erring developer/team by the same night. There are protocols like call the guy involved to get it right and ensure only code that is working is checked in . All of this boils down to the Agile concept of everything that is checked in is tested and fit for deployment into production post a formal QA team blessing the product. But otherwise the usual suspects are nailed down early and the QA goes on to find the more grueling aspects of the product committed features which have escaped the unit testing/TDD iterations.

If something out here still finds its way to the bug tracker then the developer needs to take care of UNIT TESTING / TDD best practices on ensuring his/her code works well under all circumstances and integrates with all the surround infrastructure and allied pieces of software. Software ownership and craftsmanship are truly enforced here as this goes in a loop till the process achieves some predictability on the process.