Categories
blog Videos

Use a Balanced Score Card For Your Organization


Balanced Scorecard is a effective technique to monitor and set strategic goals for Organisation. It has endured twenty years of existence and is an effective tool used in Enterprise Architecture and used widely across enterprises big and small.

Need one for your organisation when you need to revisit goals and set new ones. Track them to closure and make strategy everyone’s business instead of being handed over from the top. Watch this video on how to arrive at a basic BSC for your Organisation.

For more training

www.eturnti.com/training
https://eturnti.com/enterprise-archite…
asketurnti@eturnti.com

Categories
blog Videos

What is Enterprise Architecture?

More people in the line wanting to become architects/managers , join an architectural practice, better your existing knowledge levels and people wanting to climb the architectural / managerial ladder in your organisation can augment your skills and can benefit from this training.

What is EA is it a body of knowledge , bunch of frameworks, tools , practices , methodology , best practices ? Know what it is to know what goes behind EA practices and how they are applied to situations and derive value and showcase improvement in the organisation.

Categories
blog

How to demo stuff to people ?

How to demo stuff to people where a sense of how it works is evident and you get a sense of being taken through a journey. Tell it like a story as it is told means you are no longer the guy who is shown how the stuff works but almost get to experience what it means to own or work with that product / tech stuff or gadget. There are many  books being written on this topic such as slideology, presentation patterns and effective presentations and so on. Each of them giving you on what is needed to convey your essence to the consumer of your talk. There is a great deal of learning that Steve Jobs added to this topic and many refer to him as the epitome of someone who told a story and that too a captivating one. No one presented like Steve was the standard. Men of his caliber apart from marketing apple to the world around did in many ways up the standard for presentations and cut down on all the flab that goes with presentations. Carry with you the item that you are going to demo , build a story around it weave it together and the world is the stage for the actor/presenter.

Watched this nice presentation on regular expressions which is always an interesting topic where you can do many many wonderful things with regular expressions. It is skill which can be a great time saver and a productivity tool in software development. You learn this skill to keep your bosses and coworkers happy and most of all solve complex problems and find simple time saving solutions to perhaps writing a tool to automate tests, find the up time of a server, find CPU,memory ,RAM usages and where ever else one can lay their hands on writing scripting to ease the job at hand.

This video had everything neatly explained and is a great demo right from the way the title was named /Reg(exp){2}lained/: Demystifying Regular Expressions. The title style itself is written in a sort of regular expression way , look for the data between / / and replace it with Demystifying Regular Expression. Great presentation and a tool used in the demo written in java script is available at http://leaverou.github.com/regexplained . Tell your story and you no longer have to present it similar to love the work you do and you no longer have to work.

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

Training By eturnti on Aug 10 -11 2013….

facebook_banner

More people in the line wanting to become architects/managers , join an architectural practice, better your existing knowledge levels and people wanting to climb the architectural ladder in your organisation can augment your skills can benefit from this training. 

What is EA is it a body of knowledge , bunch of frameworks, tools , practices , methodology , best practices ? Know what it is to know what goes behind EA practices and how they are applied to situations and derive value and showcase improvement in the organisation.

Past sessions had the following mix of people attending this training developers,leads, managers,architects, business analysts , consultants working on IT projects, directors and people who are , going to be part of enterprise projects and wanted to know more on how they are managed and executed.

Following are  some of the aspirations of the candidates who attended this training in the past.

1. How are EA projects managed ?

2. How are EA metrics captured , benefits measured and calculated ?

3. What are the EA frameworks and how are they used and applied in principle ?

4. How is this applicable for product development ?

5. Justify the usefulness of EA and measure overall effectiveness of an EA program.

6. Apply these principles to IT and infrastructure projects.

7. Want to lead a team of EA architects and manage an EA project .

8. Usefulness of Togaf and Zachmann and how to apply them to real life projects and derive value. Understand these frameworks and their relevance in setting up an architectural practice.

9. Convince management on architectural best practice and able to contribute to architectural decision making in the organisation.

10. How can we keep EA technology/platform agnostic ?

11. EA and agility where do they mix and match ? Is it really feasible ?

12. How to keep EA projects in iterations well managed and accountable ?

13. Want to know what this buzz EA is all about and what does it mean as I am currently doing architecture work.

Become good at what you are doing, impress your managers,coworkers by attending this course and finally add value to yourself.

Drop a mail at asketurnti[at]eturnti[dot]com to book yourself or click here.

 

 

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.